Re: [PATCH 0/2] Custom low-level merge driver support.

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Apr 18, 2007, 19:51 UTC
Message-ID: <alpine.LFD.0.98.0704181246160.2828@woody.linux-foundation.org>
In-Reply-To: <7vzm55fqyv.fsf@assigned-by-dhcp.cox.net>

On Wed, 18 Apr 2007, Junio C Hamano wrote:

Show 8 quoted lines

> 
> But I think that is a separate issue.
> 
> The logic I said I wanted to override in the message you are
> responding to is the big toplevel if () else if () ... chain in
> process_entry(), and the nested if () else if () ... logic in
> merge_file().  They roughly implement what git-merge-one-file
> does.

Ahh.

Ok, in that case, I kind of disagree with you. I think the hardcoded merging rules (ie when two of the SHA1's match etc) are the only sane things to do _regardless_ of any merge strategy.

So yeah, we'll always do one level of merging at the pure SHA1 stage, and pick that without actually doing any file-level merging at all. I don't think that's wrong. Maybe it means that people cannot pick some really strange merge that they want on a file-by-file basis, but I think that's simply how "merge-recursive" is defined.

IOW, I don't think you should be able to turn

	git merge -s recursive

into

	git merge -s ours

by making attributes say something like

	*: merge=ours

because I think the attributes are really about what we do WHEN we hit file-level conflicts, while the "merge strategy" is a much higher-level thing. They are independent.

But maybe there is some real-world and sane usage that shows me wrong.

		Linus