Allow remote branch checkout-by-name without detaching #3371
Conversation
The idea here is that in the git CLI you will often want to checkout a remote branch like origin/blah by doing `git checkout blah`. That will automatically create a local branch named blah that tracks origin/blah. Previously in the suggestions view when checking out a branch by name, we would only show local branches and remote branches like origin/blah but wouldn't show blah as an option (assuming no local branch existed with that name). This meant users would checkout origin/blah and git would check out that branch as a detached head which is rarely what you actually want. Now we give them both options. The alternative approach we could have taken is to still show the branch as origin/blah but then ask if the user wants to check out the branch as detached or as a local branch tracking the remote branch. That approach is certainly more versatile, but it's also something you can do already by going to the remote branch directly via the remotes view. Admittedly, my approach involves less work.
jesseduffield
changed the title
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferencesYou may notice some variations in coverage metrics with the latest Coverage engine update. For more details, visit the documentation |
|
Hm, I'm not sure. To be honest, I don't use the "checkout by name" command much because it's pretty much unusable for me with the amount of remote branches we have at work (more than 3000), and since filtering the suggestions doesn't sort them by date like the remote branches panel does, I get them in some seemingly arbitrary order, so it's too hard to find the branch I'm looking for. But adding all these local copies of the remote branches makes it even more unusable for me, especially since the remote branch and its local copy often don't show up next to each other in the suggestions list, making it pretty confusing. I guess I'd prefer the other option of being asked whether I want a detached head or create a local branch. |
|
Maybe we can make it a user config? I have never wanted to checkout a detached head, so I would be cool with just setting a config that would always create a local branch and track a remote when checkout out a remote branch in the branch view. |
|
A bit of a different approach - when checking out a remote branch e.g. That way it wouldn't be disruptive for people who are used to detached HEADs, and for people who want to checkout a remote branch locally they'd just have to press |
I kind of like that idea. Played around a bit with it. Kind of like this? karimkhaleel@5279bd0 |
This doesn't really solve it, because that new branch wouldn't track the remote branch, so you'd also have to do the set upstream thing manually. |
I prefer this approach, so I made a PR that implements it: #3388. |
|
Closing in favour of #3388 (review) |
Fixes #2312
The idea here is that in the git CLI you will often want to checkout a remote branch like origin/blah by doing
git checkout blah. That will automatically create a local branch named blah that tracks origin/blah.Previously in the suggestions view when checking out a branch by name, we would only show local branches and remote branches like origin/blah but wouldn't show blah as an option (assuming no local branch existed with that name). This meant users would checkout origin/blah and git would check out that branch as a detached head which is rarely what you actually want.
Now we give them both options. The alternative approach we could have taken is to still show the branch as origin/blah but then ask if the user wants to check out the branch as detached or as a local branch tracking the remote branch. That approach is certainly more versatile, but it's also something you can do already by going to the remote branch directly via the remotes view. Admittedly, my approach involves less work.
PR Description
Please check if the PR fulfills these requirements
go generate ./...)docs/Config.md) have been updated if necessary