On Wed, 13 Feb 2008, Johannes Schindelin wrote:
>
> With XDL_MERGE_ZEALOUS_ALNUM, we use the following heuristics: when a
> hunk does not contain any letters or digits, it is treated as conflicting.
Well, I think this is interesting in itself, but..
To some degree it would be even more interesting to at least partially
separate the issue of "what conflicts" with the issue of "how do we
express things when they _do_ conflict".
IOW, it's quite possible that we want to have the ZEALOUS algorithm for
doing conflict resolution (on the assumption that we want aggressively
merge), but then when conflicts happen _despite_ being zealous in the
resolver, print out the resulting conflict with near-by conflicts merged
into bigger block.
> In other words, a conflict which used to look like this:
>
> <<<<<<<
> if (a == 1)
> =======
> if (a == 2)
> >>>>>>>
> {
> <<<<<<<
> b = 2;
> =======
> b = 1;
> >>>>>>>
>
> will look like this with ZEALOUS_ALNUM:
>
> <<<<<<<
> if (a == 1)
> {
> b = 2;
> =======
> if (a == 2)
> {
> b = 1;
> >>>>>>>
I think this is an improvement already, but to take the example that
voltspike had:
<<<<<<< HEAD:file.txt
void newfunc1()
=======
void newfunc2()
>>>>>>> merge:file.txt
{
int err;
<<<<<<< HEAD:file.txt
err = doSomething();
=======
err = doSomethingElse();
>>>>>>> merge:file.txt
this does have alnum's in the shared region ("int err") so it wouldn't
have been modified by this, but it would be nice to notice: "there were
just two small lines between two conflicts, and we could actually make the
final conflict marker _smaller_ by merging them", and just doing the
reverse of xdl_refine_conflicts(), and do a "xdl_merge_conflicts()" before
printout, and get
<<<<<<< HEAD:file.txt
void newfunc1()
{
int err;
err = doSomething();
=======
void newfunc2()
{
int err;
err = doSomethingElse();
>>>>>>> merge:file.txt
(note how this really *is* smaller: it's 11 lines rather than 12 lines,
because while we had to duplicate the two common lines in between the
conflicts (+2), we got rid of the three marker lines (-3), giving us a net
win of one line.
So the "merge adjacent conflicts" logic should actually be pretty simple:
if there is less than three lines between two conflicts, the conflicts
should always be merged, because the end result is smaller.
(And with three lines in between the end result is as many lines, but
arguably simpler, so it's probably better to merge then too).
Hmm? What do you think?
Linus
-
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
