Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd

From: Duy Nguyen <pclouds@gmail.com>
Date: Oct 9, 2016, 11:32 UTC
Message-ID: <CACsJy8BpYYJmBm32YsQyuP58uhLE+sn8WdhiHyY6xzcqPVjMVQ@mail.gmail.com>
In-Reply-To: <20161009060149.voqjoiltqi6jub7g@sigill.intra.peff.net>

On Sun, Oct 9, 2016 at 1:01 PM, Jeff King <peff@peff.net> wrote:

Show 27 quoted lines

> On Sat, Oct 08, 2016 at 10:36:13AM +0200, Johannes Schindelin wrote:
>
>> > > Maybe it's time to aim for
>> > >
>> > >   git config alias.d2u.shell \
>> > >        'f() { git ls-files "$@" | xargs dos2unix; }; f'
>> > >   git config alias.d2u.cdup false
>> > >   git d2u *.c   # yada!
>> >
>> > That would be nice. It would also allow "alias.foo_bar.shell"; right now
>> > "alias.foo_bar" is forbidden because of the config syntax, which does
>> > not allow underscores outside of the "subsection" name.
>>
>> So what about this?
>>
>>       [alias]
>>               d2u = !dos2unix
>>       [alias "d2u"]
>>               shell = 'f() { git ls-files "$@" | xargs dos2unix; }; f'
>>               exec = C:/cygwin64/bin/dos2unix.exe
>>
>> You introduce all kinds of ambiguities here that did not exist before...
>
> If you mean ambiguity between the old "alias.X" and the new "alias.X.*",
> then yes, I think that's an unavoidable part of the transition.  IMHO,
> the new should take precedence over the old, and people will gradually
> move from one to the other.

Do we really need to treat this differently than

[alias]
    d2u = !dos2unix
    d2u = C:/cygwin/bin/dos3unix.exe

Another similar case is one d2u (could be either old syntax or new) is defined in ~/.gitconfig and the other d2u in $GIT_DIR/config. In either case, the "latest" d2u definition wins.

Show 10 quoted lines

> If you mean the ambiguity between alias.X.shell and alias.X.exec in your
> example, the problem is that you have keys with overlapping meanings.
> One solution is "don't do that" (so have a key like "cmd", and another
> to select "shell or git-cmd", etc). Another is to define some rule, like
> "last one wins" (so "exec" overrides "shell" in your example).
>
> I'd prefer the "don't do that" path. The config you showed is
> nonsensical, and it doesn't really matter that much how we behave. But
> it is better still if we have a config scheme that makes it hard to
> write nonsensical things in the first place.

Any suggestion? I suppose we can have _one_ key for the command. How to execute that command (exec, shell, nocd...) are boolean options. People can still write conflicting things. We have been nice so far, always dying when the user specify conflicting command line options. We could do the same here, I guess.

-- 
Duy