Re: "git pull" doesn't know "--edit"

[Junio C Hamano <gitster@pobox.com>]

Linus Torvalds <torvalds@linux-foundation.org> 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 ;-).