Re: resolving merge conflicts?

From: Linus Torvalds <torvalds@osdl.org>
Date: May 27, 2005, 05:15 UTC
Message-ID: <Pine.LNX.4.58.0505262202050.17402@ppc970.osdl.org>
In-Reply-To: <429698A0.1020008@pobox.com>

On Thu, 26 May 2005, Jeff Garzik wrote:

> 
> So is there a doc or something that describes how to resolve merge 
> conflicts?

Dang. Not really. I've always done them just by hand.

> Presumably I look at .merge_file_*, and make sure that all necessary 
> changes make it into the copy of the file in the working directory... 
> then what?  How to continue the merge?

Start from that, and when you're happy with it, just do "git-update-cache" when the file is to your liking, and re-do

	git-merge-cache git-merge-one-file-script -a

if you forget where you were and what other files you need to do by hand (which I always do, not that I've seen a lot of merge problems).

Also, I assume that this is something cogito does better. But even the git-merge-one-script could probably be nicer.

Quite frankly, a more friendly git-resolve-script would probably do

	git-merge-cache -o git-merge-one-file-script -a

(the "-o" flag causes it to merge as much as it can automatically, instead of exiting at the first one), and git-merge-one-file-script should probably on failure do

	echo "ERROR: Leaving conflict merge in $4."
	mv "$src2" "$4"
	exit 1

instead of leaving it in the temporary file. The temp-file is good for a graphical thing (which was kind of what I was hoping for), though, so it probably depends on how you continue with the merge.

(I also like the temp-file just because _if_ you have dirty data in your tree, overwriting it with the failed merge is pretty damn impolite, but of course, you shouldn't try to merge with dirty data, and you may prefer the one that is _practically_ more friendly even if it's a bit unsafe. It's a trade-off)

		Linus