On Sat, Dec 19, 2020 at 12:59 PM Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > > Junio C Hamano wrote: > > Felipe Contreras <felipe.contreras@xxxxxxxxx> 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)
