Re: Files different for me

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 25, 2009, 18:51 UTC
Message-ID: <7v4oyi2vvf.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.2.00.0902250957260.3111@localhost.localdomain>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 21 quoted lines

> If your changes do not touch any of the files that the "git pull" updates, 
> then everything is fine. The pull will just work, and your changes will 
> still exists in your tree. This is not an accident - git was very much 
> designed to work that way, because it's a common usage case for me.
>
> I often have some trivial small changes in my tree (like a pending change 
> to the top-level Makefile for the next version number that I just haven't 
> committed yet - just a reminder to myself that I'm soon about to release 
> another -rc). And I still want to continue to do "git pull" to fetch 
> stuff, or even "git am -s" to apply patches.
>
> HOWEVER. If the pull actually wants to modify a file that you have changed 
> (ie that same file was changed in the remote), then "git pull" will fail 
> gracefully after having done the fetch, saying something like
>
> 	Entry 'file-name' not uptodate. Cannot merge.
>
> and at that point you have to decide whethe you want to commit the change, 
> "stash" it, or just undo it. Or whether you don't want to do the merge 
> yet because you're still working on your own changes, and don't want the 
> distraction.

I've been repeating the above to new people to save you time, but recently I noticed one thing.

The handling of a case where a pull decides to go ahead (because it does not have to touch the Makefile you have your codename updates in) but does not complete with real conflicts, is not as graceful as the other two cases (merge refusing to run at all without touching anything, or merge completes cleanly and makes a commit).

You will be left with:

 - Paths that have local changes (index matches HEAD but work tree does
   not match the index --- like your Makefile);

 - Paths cleanly merged (index and HEAD are different but work tree
   already matches the index);

 - Unmerged paths (index has higher stage entries with <<</===/>>> files
   in the work tree);

You, I and experienced users know what to do. Deal *only* with the last kind, mark them with "git add" after you are done with each of them, and make sure you do not say "-a" when committing the result, to exclude the first kind from the merge result.

I've been wondering if we can make this safer for others.