Re: Git: Unexpected behaviour?

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 14, 2011, 20:55 UTC
Message-ID: <7vr51aifug.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAOeW2eEUbvd0eJHjNfbvi9QnDiUO=mFA9rrKsjv8Yu0_QiPgSw@mail.gmail.com>

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

Show 8 quoted lines

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