Re: [PATCH] git: show alias info only with lone -h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> Another interesting case: even for our own commands, the alias itself
> may add extra arguments, which confuses things further. So:
>
>   $ git -c alias.gi='grep --cached' gi -h
>   'gi' is aliased to 'grep --cached'
>   fatal: no pattern given
>
> runs git-grep, but even though the user said only "-h" the alias added
> another option which prevents the help-mode from activating.
>
> In this case it is not too harmful, but you can come up with
> pathological cases where it actually runs a real command:
>
>   git -c alias.grep-for-foo='grep -e foo' grep-for-foo -h
>
> which runs a real grep.

Yes, that is an excellent point to further argue that we should fix
the help-alias case to stop there after describing the alias.  The
user can choose to do "git grep -h" and look for "--cached" after
learning that their 'git gi' is a shorthand for 'git grep --cached",
but we shouldn't be doing so.

> I guess one way to deal with it would be if the user runs "foo -h", and
> alias.foo is "bar --other arguments", then we run just "bar -h",
> dropping the extra arguments provided by the alias.

It is much simpler and saner to just stop after giving the alias
expansion, isn't it?  Nobody can get hurt if we did so; doing
anything else would be driving us into further corner cases that
would either confuse or harm the users.

> So IMHO the patch under discussion is a strict improvement, even though
> it leaves many other questionable cases unsolved.

That part I 100% agree with.  Let's accept the change, and then give
further fixes in related areas.

> I'd also be happy if on top we did:
>
>   1. When alias.foo="bar --options", turn "git foo -h" into "git bar
>      -h", dropping "--options".

This smells like piling more voodoo magic on top, which I am not
enthused.

>   2. When alias.foo="!bar", report only the alias and do not run "bar"
>      at all. The collateral damage here would be:
>
>         !git bar $(some_shell_magic_we_need)
>
>      but IMHO that is not all that bad. If we report the alias content,
>      the user can probably figure out which "git help" to run next.

This I very much like, and further, I would prefer to do this for
all aliases.

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux