Re: [PATCH 5/8] rerere: use ll_merge() instead of using xdl_merge()

Johannes Sixt [off-list ref] writes:

On Sonntag, 17. Januar 2010, Junio C Hamano wrote:

quoted

This allows us to pay attention to the attribute settings and custom
merge driver the user sets up.

I do not think that this change is necessary; I even think that it is wrong, 
in particular, custom merge drivers should *not* be used anymore.

You are right in that nothing is strictly necessary as long as there are
other ways to do so.  This does not have to be how the issue is solved,
but I found this to be one and the most natural way to allow rerere to pay
attention to per-path conflict marker length attribute.

Contents that you would want to use custom merge drivers would not benefit
from the current rerere that uses the default textual merge. In your
customized XML merge editor example, the merged contents have irrelevant
line breaks on either side of the merge that break textual merge (and that
is the reason you are using a custom XML aware merge script to begin with).

So I didn't think using ll_merge() makes things worse, and that was the
reason why I did it this way.

But I admit I didn't think things through (and that is why your name was
on the Cc: line).  If you really want to forbid custom merge drivers, I
think we can add an option to ll_merge() to specify which attribute to
ignore, and force the default textual merge in the codepath, or we can go
back to the xdl_merge() but pass a custom conflict marker length in
xmparam_t, as a follow-up fix.

On Sonntag, 17. Januar 2010, Junio C Hamano wrote:

So I didn't think using ll_merge() makes things worse, and that was the
reason why I did it this way.

Thinking a bit more about it, the problematic point is not that a custom merge 
driver is used, but it is the way how conflicts are marked. For example, it 
seems a bit strange that an XML merge driver would mark-up conflicts using 
<<<<<<< and >>>>>>> in random points of XML text, when it knows that the 
result would be invalid XML (and subsequently an XML editor could fail to 
parse the result). It would be more apropriate when it used a different way 
to mark conflicts.

The conclusion is that your approach goes in the right direction. But since 
the result depends on the traditional conflict markers, it keeps rerere tied 
to the standard text merge driver. The capability that rerere will use custom 
merge drivers is of little use (unless the merge driver uses standard 
conflict markers); that it allows attributes for the standard text merge, is, 
of course, a plus.

-- Hannes