I would like to make a series of significant improvements to the
merge-recursive mechanism in git, but I was hoping to solicit some early
feedback before submitting patches.

First, git is overly zealous at merging differences and two functions  
added
at the same point in a file become intertwined during the merge. A  
trivial
example of this behavior:

   <<<<<<< HEAD:file.txt
   void newfunc1()
   =======
   void newfunc2()
   >>>>>>> merge:file.txt
   {
     int err;
   <<<<<<< HEAD:file.txt
     err = doSomething();
   =======
     err = doSomethingElse();
   >>>>>>> merge:file.txt

Second, git doesn't tell me the original code inside the conflict  
markers so
I almost always resort to "MERGE_HEAD...ORIG_HEAD" and
"ORIG_HEAD...MERGE_HEAD" diffs to see what was going on. I could use an
external diff tool (yuck), but I would like to modify the conflict  
markers
to resemble those of Perforce:

   >>>>>>> merge-base:file.txt
   Original code.
   ======= HEAD:file.txt
   Head code.
   ======= merge:file.txt
   Merged code.
   <<<<<<<

Third, git doesn't appear to have any sense of context when performing a
merge. Another contrived example which wouldn't be flagged as a merge
conflict:

   ptr = malloc(len); // Added in HEAD.
   init();            // Included in merge-base.
   ptr = malloc(len); // Added in "merge".

Fourth, git doesn't provide a mechanism for merges to ignore whitespace
changes.

I resolved issues the first and the fourth through the introduction  
of new
configuration variables and trivial modifications to the manner in  
which we
call xdl_merge. I suspect the second and third issue may also be  
simple to
solve but would require that I modify libxdiff directly.

Are these changes something other people might be interested in? (It  
seems
odd that nobody is complaining about these really irritating flaws.)  
Should
I concern myself with writing a custom merge driver rather than  
modify core
behavior (even if the change is configurable)?  If I should focus on an
external driver, under what circumstances would merge.*.recursive  
come into
play (i.e., when do I have to worry about poor behavior for an "internal
merge")?

Thank you in advance for the feedback.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html