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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Dec 19, 2020, 20:59 UTC
Message-ID: <5fde69944fe4d_1e50c7208f@natae.notmuch>
In-Reply-To: <xmqqlfdtoch2.fsf@gitster.c.googlers.com>

Junio C Hamano wrote:

Show 19 quoted lines

> 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.

Show 9 quoted lines

> 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.

Show 8 quoted lines

> > 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.

-- 
Felipe Contreras