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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Sixt <j6t@xxxxxxxx> writes:

> On Sonntag, 17. Januar 2010, Junio C Hamano wrote:
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]