Re: merge strategy request

"Martin Langhoff" [off-list ref] writes:

Would it be possible to have an env var (GIT_MERGE) that can be used
to call an arbitrary script with merge/diff3 semantics instead of
using the internal 3-way merge? That way we could do syntax-specific
merges (ignore comments/whitespace, for example).

I do not think such a patch is hard, as calling external merge
for file-level merge is what we used to do.  It's just a matter
of resurrecting the code we threw away and making it be called
conditionally.

But a more interesting point is "under what condition".  If the
condition is "when GIT_MERGE environment is defined", it is not
much better than what Dscho suggested, as the external merger
would be called for all paths.  We would want a mechanism to
decide use of such a specialized merge backend for special
cases, which is where gitattributes comes into the picture.
Especially because there would be one specialized to merge xml
documents, one to merge gimp xcf files, and another to merge
gentoo configuration files (or whatever the original thread
starter wanted).

i would surely have a use for it, as sometimes my internal team is not
_that_ good about trimming whitespace, and we have merges that succeed
except for their whitespace conflicts.

I know Linus does not like applying patches with whitespace
fuzziness, but I personally think a merge that ignores
whitespace changes would be a useful thing to have, without
having to call an external specialized merge backend. In other
words, I do not think it is so special a thing to want to, but
it is rather an unfortunate norm.  I am not opposed to give
git-merge-recursive a command line option to tell it to merge
ignoring the whitespace-only changes, when it does the 3-way
file-level merge internally.

There is a small detail of how to pass such a command line
option to git-merge-$strategy backends, though.

On 3/26/07, Junio C Hamano [off-list ref] wrote:

But a more interesting point is "under what condition".  If the
condition is "when GIT_MERGE environment is defined", it is not
much better than what Dscho suggested, as the external merger
would be called for all paths.

Well well... no. Unless you mean all paths that need diff3 merging
(that is, all paths that changed on both sides). And in that case, the
script itself can have the "change policy depending on file extension
or phase of the moon" machinery. I think it makes it more powerful
because it can have specialised logic for this -- where the git
machinery is going to be limited to simpler rules (like file
extension).

In any case, it is a _different_ mechanism to saying "all changed
paths on either side". I don't know if there is even an interesting
case for that.

it is rather an unfortunate norm.  I am not opposed to give
git-merge-recursive a command line option to tell it to merge
ignoring the whitespace-only changes, when it does the 3-way
file-level merge internally.

That'd be great to have. How about both? ;-)

cheers,


m