Thread (2 messages) 2 messages, 2 authors, 2016-06-15

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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:05


On Wed, 18 Apr 2007, Junio C Hamano wrote:
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help