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

[Junio C Hamano <junkio@cox.net>]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Wed, 18 Apr 2007, Martin Waitz wrote:
>>
>> > 	[merge.driver]
>> > 		ancient = merge %A %O %B
>> 
>> or
>> 
>> [merge "ancient"]
>> 	driver = merge %A %O %B
>
> Much better. That format also allows you to add extra flags if you want. 
>
> For example, it might be useful to add something like
>
> 	[merge "ancient"]
> 		name = external three-way merge
> 		driver = merge %A %O %B
>
> so that you could make the merge process actually say what it is doing 
> when it's merging things. Wouldn't it be nice to see
>
> 	merging file xyzzy using external three-way merge
> 	merging file fax.doc using word file merge
> 	..
>
> when these things trigger?
>
> So even if we do *not* care about the name, this kind of config structure 
> is just more flexible. 

Yes.

While I agree with all of the above, I am currently fighting
with a back-to-drawing-board design problem.

The series made the low-level 3-way merge machinery
customizable, which is a progress, but I think merge-recursive
needs a hook to affect middle-level merge decision, similar to
what git-merge-one-file does.

I wanted to use 'ours' merge for RelNotes, which typically
points at the release notes being prepared for the next release
from the branch (Documentation/RelNotes-1.5.1.1.txt for 'maint',
and Documentation/RelNotes-1.5.2.txt for 'master').  As I never
merge 'master' into 'maint', using 'ours' merge for that path is
the right thing to do in this case.

But merge-recursive has a built-in middle-level decision that
makes a conflicting symlink modification never go through the
low-level 3-way merge codepath.

This was originally not a problem, as the low-level 3-way merge
used to be always "textual merge" that would never make sense
for symbolic links, but once we allow low-level merge driver
that could be "pick one of branches", it becomes needless
constraints.

For now, I'd stop at pointing this issue in this message, and
finish up the configurability of low-level merge driver first
and merge that to 'next'.

But I *think* we would end up revising the driver definition to
take more than %A %O %B and allow it to do more than the
low-level decision.

Perhaps...

	(in .gitattributes)

	RelNotes	merge=ours

	(in .git/config)
        [merge "ours"]
        	name = middle level 'ours' merge driver
                driver = exit 0
                middlelevel

when "merge.$name.middlelevel" boolean is set, it would forbid
process_entry() to make the 'git-merge-one-file' policy decision
and always call the driver with these in addition to the %O %A
%B:

	%OSHA1	object name for ancestor version (or 0{40} for missing)
        %OMODE	mode bits for ancestor version (or 0{6} for missing)

The driver should be able to express the merge cleanliness via
exit status, and the resulting (potentially partial) merge
result blob via %A as the low-level driver, but in addition to
them it needs to be able to say "the merge result is to remove
that path".  I haven't figured out what that interface should
be; we could designate one special exit code to signal that,
perhaps "exit 42", but that feels hacky.

In any case, making [merge "driver-name"] section with 'driver'
variable leaves the door open for such extension in a backward
compatible way by leaving room to add 'middlelevel' boolean like
the above outline, so I'd stop worrying about this for now,
without doing anything further.