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

From: Jeff King <peff@peff.net>
Date: Oct 9, 2016, 20:58 UTC
Message-ID: <20161009205854.byq2wqgemtmwudfb@sigill.intra.peff.net>
In-Reply-To: <CACsJy8BpYYJmBm32YsQyuP58uhLE+sn8WdhiHyY6xzcqPVjMVQ@mail.gmail.com>

On Sun, Oct 09, 2016 at 06:32:38PM +0700, Duy Nguyen wrote:

Show 16 quoted lines

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

Yeah, that's reasonable, too. So:

  [alias]
    d2u = "!dos2unix"

acts exactly as if:

  [alias "d2u"]
    command = dos2unix
    type = shell

was specified at that point, which is easy to understand.

Show 12 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).
> [...]
> 
> 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.

Having separate exec/shell boolean options just punts the overlap from the command key to those keys. If you have two mutually exclusive options, I think the best thing is a single option, like:

  type = <shell | exec | whatever>

and then it is obvious that a second appearance of "type" overrides an earlier one, by our usual "last one wins" convention. As opposed to:

  shell = true
  exec = true

where you have to understand the meaning of each option to know that "exec" overrides "shell".

-Peff