Thread (1 message) 1 message, 1 author, 2016-06-15

Re: Git: Unexpected behaviour?

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:52:28

Martin von Zweigbergk [off-list ref] writes:
Either you want the modifications to stay on the branch, or you want
them to carry over to the branch you are checking out. In the former
case, you would want Git to fail if there are modifications (that you
might have forgotten you made). In the latter case, you would want
"git checkout -m". The current behavior is somewhere in between. It is
not clear to me if there is a use case where the current behavior is
better (from the user's point of view) than either failing or
"checkout -m".
Current behaviour is deliberately made safe because "checkout -m" may end
up forcing you to resolve a 3-way conflict you may not be prepared to do
correctly at your first attempt. Stopping and refusing to check out the
other branch gives you the choice to create a temporary stash-away commit
either on a current branch, or a temporary branch you create with "git
checkout -b temp && git commit" before switching to the target branch to
attempt to port the change over with "git cherry-pick @{-1}", which you
_can_ redo if you screw up conflict resolution and want to start over.
If you are confident that your local changes are trivial that you can
reproduce it even if you screw up your conflict resolution attempt, then
you can choose to run "checkout -m". If we made it the default, you will
lose this safety.

On the other hand, if you do *not* want to carry over the change when
checking out a different branch, you can easily stash-away the changes.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help