You have local changes; cannot switch branches error question

First of all Merry Christmas and Happy New Year to everybody! I wish Git to move to global dominance during next year even faster then it does now;)

My question is related to the fact that most of the time when i have some local file changes Git is switching branches OK. But from time to time in some repos I'm hitting this error and I cannot figure out why it suddenly starts to complain about it?

For example in one of my repos I somehow got to a state when I have three files modified, and when I'm trying to switch branches it complains about one of them being changed locally, so it refuses to switch branch

OTOH i have tried many different scenarios in another repo to leave some uncommitted staged or not staged changes and switch branches and same version of git does that just fine. (v 1.6.5.6).

So, what is correct behavior - do not switch or switch branches when there are uncommitted changes?

Thanks, Eugene

Quoting Eugene Sajine <euguess@gmail.com>

The command is telling you that it refrained to overwrite your local changes. It's not complaining. There is an excellent summary of what switching branches with 'git checkout' while you have local changes in your working tree.

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

Eugene Sajine <euguess@gmail.com> writes:

Suppose you have a history like this:

         o---B side
        /
    ---o----o----A master

and both branches 'master' and 'side' have file, F and G. G is different between commits A and B while F is the same between these two commits.

You have 'master' checked out, and modified both F and G. This table shows the contents you have in each path:

    path    master      work tree    side
    -----------------------------------------
       F    F1          F2           F1
       G    G1          G2           G3

In git, your local modification does _not_ belong to any branch. You need to commit them if you want to make them part of the history of your current branch. Checking out a different branch means you switch to the branch and carry these changes along with you. But it is not necessarily be possible to do so without modifying what is in your work tree.

For path F, your local change is (F2-F1), and switching to branch 'side' means you would transplant that change on top of what that branch has, which happens to be F1. That means the result is F2 (= F1 + (F2-F1)). IOW, because F is identical between master and side, the file in your work tree can stay the same.

Now, think what should happen to path G. The local change is (G2-G1), and you need to transplant that change on top of G3, that is different from G1. This computation will involve a merge, which you may or may not be prepared to resolve.

If you are used to CVS/SVN workflow where you "update" to merge other's changes to your work tree with your own local changes, you will know that with such a merge, depending on the amount of change between G1 and G3, you may end up losing quite a lot of work of your own (G2-G1), when the merge is too complicated for you to handle. The message you saw is a safety valve to prevent you from trashing your work that way.

There are two ways to deal with this situation, one safely, and another quickly.

 - You can "stash save" to first save the changes in your work tree,
   "checkout" to switch to branch 'side', and then "stash pop" to attempt
   the merge.

   The last step of unstashing on the new branch _will_ give you the same
   kind of conflict while computing G3 + (G2 - G1) to update file G, but
   the approach has one huge advantage compared to CVS/SVN's "update", in
   that you can "reset --hard" and "stash pop" to reset to a clean state
   and attempt resolution if you failed resolve conflicts and end up
   making a mess in your first try.

 - If you _know_ that the changes between G1 and G3 do not conflict with
   what you did between G1 and G2, you can "checkout -m" to instruct it to
   act as if it were CVS/SVN's "update" command.

   This can potentially make an unresolvable mess in your work tree, and
   you can end up losing your changes G2-G1, but it is quicker than "stash
   save"/"stash pop" pair.

Junio C Hamano <gitster@pobox.com> writes:

And a third one : commit, and then rebase onto the other branch. It's safe, and nice when your local changes are ready to commit (then, you can write the commit message before bothering about potential merge conflicts).