Re: Files different for me

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, 25 Feb 2009, Junio C Hamano wrote:
>
> 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).

I agree (although your phrasing was confusing - by "does not complete with 
real conflicts" you made it sound like there were no real conflicts, but 
you must have meant "does not actually finish the merge commit _due_ to 
real conflicts").

That case is one large part of why I wanted to have that "git reset 
--merge" behavior - because it's a good way to get back to the "pre-merge 
with dirty state" situation. Although I have to admit that I don't think 
I've had that happen since the feature got merged ;)

> 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);

Yes. The good news is that for people who know what they are doing, this 
is all unambiguous. Clean merges will be up-to-date in the index, unmgered 
paths will be marked as such in the index, and your own _real_ dirty state 
will be unambioguously dirty in the working tree.

But I do agree that if you don't know what's up, you now are an in a 
really good position for screwing up, and (for example) resolving the 
merge conflict and then incorrectly committing your own unrelated changes 
with the merge.

> 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.

You're right. We could decide to have a mode (maybe default to it, so that 
people like me can just use a config option to enable "expert" mode) that
simply refuses to do the merge if it doesn't succeed cleanly if there were 
dirty files in the tree.

			Linus