Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > In the docs, the "GIT_MERGE_AUTOEDIT=no" thing is mentioned as the way > to get the legacy behavior, which (at least to me) implies that > setting it to "yes" gets the modern behavior. Honestly, I didn't actually intend to accept any value other than "no" to be set in that variable. Also the variable's name was way suboptimal. I didn't intend "Auto" to describe "Edit" (as in "is the editor spawned AUTO-matically? yes/no"), but meant it to describe "Merge" (as in "When a merge results in AUTO-committing, do we edit it? yes/no?"). > Maybe this is intentional, and not a bug? But it does seem a bit odd - > the name is "AUTOEDIT", not "FORCEDEDIT". A clean merge that tries to start an editor even when not interactive is honoring the "yes" setting is understandable/explainable if you read the misnamed variable as "When a merge results in AUTO-committing, do we edit it? yes/no?" But it of course does not mean that such a behaviour is useful. It is not just "a bit odd", it is outright useless in a text terminal, especially when you are redirecting the input from /dev/null ;-). > Or maybe the thing could extend the notion of the current boolean to > be a tri-state instead: in addition to the traditional true/yes/on and > false/no/off have a "force" mode that is that "always force it on > regardless". Yeah, if we support any value other than "no", I think the trivalue always/auto/never (aka yes/auto/no) would make the most sense. > And maybe this is just a "nobody cares" situation - "Don't do that then". I would have agreed with you 3 years ago, but these days I find the end users are being much pickier than they used to be ;-). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html