Re: You have local changes; cannot switch branches error question

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.