Handling merge conflicts a bit more gracefully..

Ok, Jeff reported that whenever there is a merge conflict, he ends up really punting on it and doing it all with diffs, which clearly meant that I had to fix up my silly things for this. Which I think I've done now.

What happens now in the case of a merge conflict is:
 - the merge is obviously not committed
 - we do all the successful merges, and update the index file for them
 - for the files that conflict, we force the index to contain the old
   version of the file (ie we remove the merge from the index), and we
   write the (failed) output of the merge into the working directory, and
   we complain loudly:

	Auto-merging xyzzy.
	merge: warning: conflicts during merge
	ERROR: Merge conflict in xyzzy.
	fatal: merge program failed
	Automatic merge failed, fix up by hand

at which point a normal "git-diff-files -p xyzzy" will show the incomplete merge results (as relative to the original BRANCH you started with), and in fact you can also do "git-diff-cache -p MERGE_HEAD xyzzy" to see the same thing (but relative to the branch you tried to merge).

You then fix up the merge failure by hand (exactly the way you'd do with CVS), and you do a "git-update-cache xyzzy" when you're happy with the end result. Then a simple "git commit" should do the right thing.

If you decide that the merge is too hard to undo, you'd do:

	git-read-tree -u -m HEAD
	rm .git/MERGE_HEAD

and use git-checkout-cache judiciously to remove any edits the merge did.

This is definitely not perfect, but it's a hell of a lot more usable than it used to be, and not really worse than what CVS people are used to (and usually a lot better, since git will obviously get the origin of a three-way merge right, unlike CVS).

Comments? It would be good to have people test this and maybe even write a few automated tests that it all works as expected..

		Linus