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

On Sat, Feb 11, 2012 at 10:21 AM, Linus Torvalds
[off-list ref] wrote:

Ok, so now "git merge" defaults to editing when interactive - lovely. But
when testing that,

Ok, I found another thing that seems to be a buglet, or at least an
undocumented surprise.

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.

But try this:

    .. create test branch that can be merged ..
    export GIT_MERGE_AUTOEDIT=yes
    git merge test < /dev/null

and notice how the "GIT_MERGE_AUTOEDIT=yes" will actually *override*
the automatic merge thing, and will try to start an editor even for
non-interactive sessions.

Maybe this is intentional, and not a bug? But it does seem a bit odd -
the name is "AUTOEDIT", not "FORCEDEDIT". And  at least my default
editor gets confused by the redirected input, although obviously if
you have a graphical editor in its own window this may well be what
you want.

Anyway, maybe the "return v" in default_edit_option() should be

    if (!v)
        return 0;

instead - so that if AUTOEDIT it set to true, it does what the "auto"
in the name implies.

Of course, the current behavior *can* actually be useful, exactly as
that way to force the editor to come up. So maybe it's just that my
expectations that are wrong, and the behavior that "yes" causes a
forced editor should just be documented instead.

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".

And maybe this is just a "nobody cares" situation - "Don't do that then".

                    Linus