Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views

[Junio C Hamano <gitster@pobox.com>]

Felipe Contreras <felipe.contreras@gmail.com> writes:

>> Another reason why allowing users to disable the feature per tool is
>> important is because as far as I know we have kept the mergetool
>> framework to allow adding a tool that can merge binary data, and
>> leaving these three files pristine was one ingredient for that.
>> With only a single knob, we would be making a decision to declare
>> that such a tool is unwelcome, which is not quite acceptable.  I
>> expect that users would want the new feature most of the time
>> because they would be managing text files more of the time, and
>> having only a single knob would force an unnecessary choice on those
>> who want to use such a binary-capable tool as well.
>
> I can't imagine what that binary data could look like, and how any tool
> could represent that to the user.

What I had in mind are use cases like merging "comment"-ish part of
media files (e.g. exif in jpeg, id3 in mp3---things like that), as
I've heard some people do use Git to manage their photo collection.

Of course, I can imagine that a cartoonist first draws a background
picture, cop es it twice, and then draws a dog on top of the
background in one copy while drawing a cat in the other.  You should
be able to merge the resulting two pictures cleanly by following the
three-way merge idea (take what got changed on only one side plus
what did not change--anything else is a conflict) as long as these
animals do not overlap.  You probably can even do an equivalent of
-Xours (not --ours) to essentially say which object is closer to the
viewer in a conflicting case.

> But either way "git merge-file" fails on those cases, so we can just
> check if the file is empty, and bail out.

Catching failures from merge-file and reverting back to the original
behaviour would be an improvement, if the code in the earlier
iteration was not checking errors.  But I would prefer not count on
the tool always to fail, as there are image file formats that appear
to be text that are unreadable to humans (like pnm), and my primary
reason for configurability is as an escape hatch to be used in cases
where we do not anticipate here.  Listing "what about this case, it
does not break" million times would not help us here.

With per-tool enable/disable option, the users do not have to rely
on failure from merge-file anyway.

Thanks.