Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Eugene Sajine <euguess@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: You have local changes; cannot switch branches error question
Date: Thu, 24 Dec 2009 15:32:24 -0800	[thread overview]
Message-ID: <7vhbrghrsn.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <76c5b8580912241425k741b24e9ie8ed92ca7cb8a659@mail.gmail.com> (Eugene Sajine's message of "Thu\, 24 Dec 2009 17\:25\:37 -0500")

Eugene Sajine <euguess@gmail.com> 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.

  parent reply	other threads:[~2009-12-24 23:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-24 22:25 You have local changes; cannot switch branches error question Eugene Sajine
2009-12-24 22:59 ` Nanako Shiraishi
2009-12-24 23:32 ` Junio C Hamano [this message]
2009-12-25 14:32   ` Matthieu Moy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vhbrghrsn.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=euguess@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox