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

On Sat, Feb 11, 2012 at 10:21 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

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