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