Eugene Sajine <euguess@xxxxxxxxx> writes:
> 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
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html