On Sat, Feb 11, 2012 at 10:21 AM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html