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