Closed zimiarh closed 5 years ago
Okay, I found out that when your working branch is not tracking the remote branch that you are about to checkout, checking the remote branch out actually checks out the local branch.
I feel this behavior is a little bit confusing because after the action the user is (very likely) transferred to a revision that is not the one that was selected and supposed to be checked out.
I'd like an option to reset the local branch to the remote branch (unless there are local-only commits) and to checkout the (updated) local branch in a single operation.
That would be very useful on big repositories (slow checkout) that change quickly.
@ltrzesniewski I found a way to do this in two steps that doesn't include multiple checkouts:
The current behavior is extremely confusing. I would much prefer a popup to say ("Would you like to reset your local branch to match this remote?")
The current behavior is unlike other git clients I am used to. It is counterintuitive and misleading for the user -- pointing my mouse to one line of the tree (the remote head) and selecting "check out" can actually end up checking out something on a totally different line of the tree (the remote head). It is very easy not to notice that this switcheroo has happened!
When I point my mouse to a specific commit of the tree and go to "checkout..." the branch, I expect the checkout to retrieve that commit!
Please fix this issue!
@JackZylkin
I would much prefer a popup to say ("Would you like to reset your local branch to match this remote?")
what should happen if your local branch contains unpushed changes?
If you select "Yes" your branch gets reset. Otherwise, your branch is rebased onto the remote.
Some global setting could do a pull (merge) instead of a rebase, but I personally would prefer a rebase.
Actually, if you say "no" your branch should stay the same and the behavior is the same as it currently is in Fork. A third option might be to allow people to rebase the two branches together, if there are in fact new commits on each one. So the prompt would say "You already have a local branch tracking this remote, but the two are not in sync. Before checking out, do you want to: a) Update the local branch with any remote changes. b) Reset the local branch to match the remote (discard local changes). c) Check out the local branch as-is.
A simpler solution would be just to say: "You already have a branch tracking this remote. Would you like to create another one?"
@ltrzesniewski I found a way to do this in two steps that doesn't include multiple checkouts:
Right-click the local branch and select [branch name] > Fast-Forward Pull Check out the local branch
This only works if you are really paying attention and realize that you already have a local branch tracking the remote, and you have the presence of mind to go find that branch and update it before checking out the remote branch. If you don't remember to do that, or don't realize you have to, you will be frustrated and confused that the code shown in your repo is not the code from the revision you meant to check out.
OK, what do you guys think if we implement the following behavior?
I agree with this approach.
However, in the third case, I would also appreciate an option to "damn the torpedos" and reset the local branch entirely (without any attempt to fast-forward). This is the only way to guarantee that the commit you have selected with your mouse is actually the commit you will be checking out.
@JackZylkin something strange happened to your comment. How could it be made in the future?
Where are you located?
Wow, GitHub gone mad, my commit appeared before yours.
I am located in Pennsylvania. I'm not sure why the message appeared in the future. Odd.
Thank you for considering this issue -- I feel it is very important for my team, who often work on multiple computers, and therefore want to frequently and reliably check out the same commit of the same remote branch in multiple workspaces.
Will this be tracked as a feature request?
Yes, we are working on that.
The feature is already implemented, but we could not make a clear UI layout yet. In my post above I forgot that we also need to manage 'Stash and reapply and 'Discard' checkout options.
We will try to make it appear in the next update, but this is not 100%.
This issue appears to be addressed in Fork 1.34. If a local branch is lagging behind the remote, checking out the remote causes the local branch to catch up. If the local branch has changes that the remote doesn't have, an option to fast-forward is presented.
Thanks very much for picking up this issue so quickly. I am sure this will improve the experience greatly for my team. I will let you know how the new feature works for us.
If the local branch has changes that the remote doesn't have, an option to fast-forward is presented.
Not sure I understand what you mean. Could you show a screenshot please?
There is one odd behavior I noticed with this new feature -- if your local is ahead of the remote (lets say it has one commit that the remote doesn't have) and you try to check out the remote, you are given the option to fast-forward. This doesn't make sense because in this scenario fast-forwarding would have no effect. In this scenario the prompt is a bit confusing the user, who does not know the rationale discussed in this thread.
ne com
When there is no local tracking branch, checking out a remote branch in Fork creates a tracking branch. However, when a tracking branch already exists, checking out the remote branch does nothing.
What is the expected behavior? If such action should not have any effect (i.e. current behaviour is the desired one), would it be better to not letting the user to perform it in the first place?