Re: Better cooperation between checkouts and stashing

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 1, 2010, 20:40 UTC
Message-ID: <7vhbq0wuy6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4B67227A.7030908@web.de>

Markus Elfring <Markus.Elfring@web.de> writes:

Show 10 quoted lines

> The content control tool "Git" maintains a single file system view that can be
> actively worked on. It can be switched to different topic branches by the
> command "git checkout". If the current active working copy contains "dirty"
> changes, they need to be stashed away before each switch to a different issue.
> http://ariejan.net/2008/04/23/git-using-the-stash/
>
> I imagine that there are opportunities for further improvements.
> - How do you think about the feature that a checkout performs also a stash
> operation before by default and a stash would offer the option to checkout a
> branch afterwards in one step?

If you are starting from "if your work tree is dirty, you MUST stash before checking out another branch", the suggestion is understandable. But the thing is, that starting point is not quite correct. And the end result is that such a change you are suggesting would inconvenience people greatly, I am afraid, if not designed carefully (I'll outline at the end).

Checking out another branch (branch switching) is designed to carry your local modification across with you. This is to allow you to start working on something, realize that your changes are better suited for another branch, and at that point after the fact "git checkout" that other branch, while keeping what you have done so far.

If the original branch you started your work from and the branch you are checking out have different contents in files you have changed (aka "your changes conflict at the paths level"), without -m option, "git checkout" refuses to check out the other branch, because it will need a three-way merge to carry your changes forward, and you might not be prepared to resolve conflicts resulting from such a merge.

In practice, however, your changes often don't conflict with the changes between the branches at the paths level, and "git checkout" lets you carry your local changes across just fine. I'd say this is the majority of the case especially for experienced git users, as they tend to commit in smaller and more logical units than those from other SCM background.

Forcing auto-stash on them would mean they now have to pop the stash, after checking out the other branch, which is not an improvement for them (and remember, soon you will be part of "them" after getting used to git). Doing an auto-pop in addition to your auto-stash "to help them" is even worse, as you essentially made "git checkout other-branch" to always use "-m" option.

I actually have explained this at least a few times here in the past:

 http://thread.gmane.org/gmane.comp.version-control.git/77700/focus=77708
 http://thread.gmane.org/gmane.comp.version-control.git/135661/focus=135663

but I don't see anything that states clearly that "checkout" is designed to carry your local changes across in any documentation (I gave a cursory look to the user manual, tutorial and checkout manual page). Probably "git checkout --help" needs a "Switching branches" section, just like the planned enhancement for "Detached HEAD" section.

We _can_ start experimenting with an option (similar to "checkout -m"), which does:

 - Internally try 'git checkout other-branch' without disturbing the user
   with any error message; if it does not fail due to paths level
   conflicts, we have successfully checked out the other branch and we are
   done;

 - If the above trial would fail for some other reason (perhaps your index
   was unmerged), then don't do anything---just fail as before;

 - Internally run 'git stash', then run 'git checkout other-branch'.  If
   either of these steps fail, you are in deep trouble.  Design what you
   have to do carefully in this case (I won't do that in this message);

 - Then finally run 'git stash pop'.