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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 12, 2012, 09:59 UTC
Message-ID: <7vlio8l6e3.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CA+55aFwLqvVyMipun4DM4CnbO97Dota3LCM2VPFfLq1LS5a4aQ@mail.gmail.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 ;-).