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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
