Junio C Hamano wrote: > Seth House <seth@xxxxxxxxx> writes: > > > On Thu, Dec 17, 2020 at 08:49:13PM -0600, Felipe Contreras wrote: > >> And no person is the sole arbiter of truth, in this list, or anywhere. > >> People have managed to change Junio's mind. > > > > I'm not worried about Junio but I am wondering if anyone has managed to > > change your mind. You and I have been going back and forth on this list > > and on Reddit for two solid days and, to be frank, I'm running out of > > steam. > > ... > > I, as a user of diffconflicts, may want to both disable this flag for > > diffconflicts but enable this flag for VS Code and kdiff3. It is not > > unusual for people to use more than one mergetool. Some of them are > > better or worse at visualizing different kinds of conflicts. Sometimes > > a conflict is small and straightforward; othertimes a conflict is > > complicated and requires deep knowledge of the history of both branches. > > If we force this to be a global flag only then users will not be able to > > make different choices for different tools. > > > > Someone who does use multiple mergetools but only uses tools from group > > one may appreciate a single global flag so s/he doesn't need to set it > > for each tool. > > ... there's every possibility that a user will prefer it a different > > way or that a mergetool author will. And there's every possibility that > > there will be differing opinions between users and authors like there is > > between you and me. But that's ok! Because it's just a configuration > > option. > > Well explained. I do not think I need to add much. > > It makes sense to at least allow people to enable/disable the > behaviour independently for different tools. When unconfigured, I > would say we should enable the feature by default to give it wider > exposure. > > Because what I care is not about the set of tools we happen to have > right now, but is about leaving users access to an escape hatch in > case things go wrong. They do have an escape hatch. > If it turns out that all the tools we happen to have do not seem to > break with this new option with just a few days' survey, Seth's blog post was ten days ago, and I presume it took him more than one day to write, so I'm not sure it's a "few days' survey". > it does not mean we do not need a per-tool escape > hatch they can use until the next release either fixes the feature > or makes it disabled by default, when there is unexpected breakages > discovered later. They don't need to wait for the next release, they can just disable the flag. These hypothetical users of multiple mergetools that are using a hypothetical mergetool that doesn't seem to exist yet can just disable the flag globally. These users have managed to survive many years without this feature enabled in all the usual mergetools, I think they would survive until the next release. > The time between a release and the next is a long > time that the users cannot keep the tool they have learned to rely > on broken. And that's a conservative maintainer's view. They don't have to; they can just disable the flag. > When a tool that never wants its input munged appears, we might > further want to have the mechanism to give different default per > each tool for users who have no configuration, so that such a tool > can be disabled while other tools are enabled by default while > allowing users to choose. But such a code to set different > enabled/disabled default per tool (the one I outlined in the > footnote of the other message) won't be exercised in practice with > the set of tools we have (hence a bug in such a code would go > unnoticed for a long time), so I tend to think we might be better > off to wait until the need arises before implementing per-tool > fallback default for users who do not configure at all. Agreed. > 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. But either way "git merge-file" fails on those cases, so we can just check if the file is empty, and bail out. I've implemented that in the next version. Cheers. -- Felipe Contreras
