fork-dev / TrackerWin

Bug and issue tracker for Fork for Windows
461 stars 10 forks source link

[Question] What is the expected behavior of checking out a remote branch when a tracking local branch exists? #136

Closed zimiarh closed 5 years ago

zimiarh commented 5 years ago

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?

zimiarh commented 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.

ltrzesniewski commented 5 years ago

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.

strawd commented 5 years ago

@ltrzesniewski I found a way to do this in two steps that doesn't include multiple checkouts:

JackZylkin commented 5 years ago

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!

DanPristupov commented 5 years ago

@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?

JackZylkin commented 5 years ago

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.

JackZylkin commented 5 years ago

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?"

JackZylkin commented 5 years ago

@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.

DanPristupov commented 5 years ago

OK, what do you guys think if we implement the following behavior?

JackZylkin commented 5 years ago

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.

DanPristupov commented 5 years ago

@JackZylkin something strange happened to your comment. How could it be made in the future?

image

Where are you located?

DanPristupov commented 5 years ago

Wow, GitHub gone mad, my commit appeared before yours.

image
JackZylkin commented 5 years ago

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.

JackZylkin commented 5 years ago

Will this be tracked as a feature request?

DanPristupov commented 5 years ago

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%.

jzylkin commented 5 years ago

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.

DanPristupov commented 5 years ago

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?

jzylkin commented 5 years ago

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.

jzylkin commented 5 years ago

image

DanPristupov commented 5 years ago

ne com