Re: Please undo "Use git-merge instead of git-resolve in

On Thu, 22 Sep 2005, Linus Torvalds wrote:

I should have continued this. 

What you do is you just edit the end result to be what it should be (exactly as under CVS), and then you do "git commit --all" to commit the manual merge.

NOTE NOTE NOTE! This is one case where if you had dirty state in your tree before the merge, that you need to be careful. In that case you obviously must NOT use "--all", since that will commit all the dirty state - both your old dirty state _and_ your manual merge resolve. So if you had other changes in your tree that you don't want to commit, you need to do

	git commit <list manually merged files individually here>

so that it doesn't commit anything else. 

Oh. And while preparing the merge, you can use

	git diff

to see what the manual part was: the automated part of the merge will have updated index for the automatic side, so this will _not_ show the part of the merge that was done automatically for you.

Or, of you want to see _everything_ the merge has done, just do

	git diff HEAD

to see what the _total_ diff from your pre-merge head was to what is now in your tree. But that will be the diff for what you're merging - so it can be _huge_ if you're pulling my tree and merging everything I've accepted over the last week or two.

And if the merge ends up being too complex, and you decide that you need help and want to undo the partial merge entirely and not even try to fix it up, do

	git reset --hard

which will roll back the index and the working tree to your old HEAD (BUT LOOK OUT! IT WILL ALSO DESTROY ANY DIRTY STATE YOU HAD BEFORE THE MERGE!).

Basically: having dirty state in your tree and then ending up having to do 
a manual merge is a big pain. Not worth it. I just keep really small dirty 
stuff so that I don't mind blowing it away if I need to.

		Linus