From: Junio C Hamano Date: Sun, 12 Feb 2012 09:59:00 GMT Subject: Re: "git pull" doesn't know "--edit" Message-ID: <7vlio8l6e3.fsf@alter.siamese.dyndns.org> In-Reply-To: Linus Torvalds 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 ;-).