Re: [PATCH] xdl_merge(): introduce XDL_MERGE_ZEALOUS_ALNUM

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 13, 2008, 02:06 UTC
Message-ID: <alpine.LFD.1.00.0802121758220.2920@woody.linux-foundation.org>
In-Reply-To: <alpine.LSU.1.00.0802130108060.3870@racer.site>

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.

Show 25 quoted lines

> 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