On Sun, Oct 09, 2016 at 06:32:38PM +0700, Duy Nguyen wrote:
> > 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.
> > 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