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

[David Aguilar <davvid@gmail.com>]

On Sat, Dec 19, 2020 at 12:59 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> Junio C Hamano wrote:
> > 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.
>
> Right. They can do that with a text editor.
>
> > 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.
>
> The whole point of separating the background from the foreground is that
> the foreground can be animated on top of the background, so they would
> always be two different files.
>
> Even if we force the issue and make two graphic artists work on two
> different branches, what they would inevitably end up doing is work on
> different layers, which for all intents and purposes are like two files.
> No mergetool is going to help them integrate their changes.
>
> > > 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),
>
> git would not add conflict markers on the part of a pnm file that did
> not change, so in fact, a person merging pnm files might in fact desire
> automerge.
>
> > and my primary reason for configurability is as an escape hatch to be
> > used in cases where we do not anticipate here.
>
> Once again: "mergetool.automerge=false" is a thing.
>
> > Listing "what about this case, it does not break" million times would
> > not help us here.
>
> This is the philosophical problem of induction: a million white swans
> doesn't prove all swans are white.
>
> The only thing we know for certain is that there is no known problem.
> And that if and when such a problem occurs, we would need to think about
> the proper solution.
>
> > With per-tool enable/disable option, the users do not have to rely
> > on failure from merge-file anyway.
>
> They don't have to rely on that failure, they can just turn off
> mergetool.automerge.
>
>
> But fine. Let's the perfect be the enemy of the good. That seems wise.


FWIW I'm in favor of having per-tool configuration precisely for
custom mergetools that do things with custom file formats and benefit
from having all of LOCAL REMOTE and BASE.

I don't have to imagine these use cases, they are very real. No survey
can be exhaustive so being flexible and allowing for a mixed tool
ecosystem is the right choice.

This design choice is also in alignment with the general
mergetool/difftool per-tool configuration paradigm.  If we didn't
support per-tool, then it would be inconsistent.
-- 
David

(sorry, posting from gmail's web interface so this probably won't hit
the public lists, but I probably won't reply beyond this email stating
my preference)