allowing aliases to override builtins to support default options

Currently git does not allow aliases to override builtins. I understand the reasoning behind this, but I wonder if it's overly conservative.

Most shells support overriding commands with aliases, and I'm not sure why git needs to be more conservative than the shell. (Although, I will say, I hate when vendors alias rm to "rm -i", etc...)

It seems like this would be an elegant way to support default options. Were it to be supported, it should probably have an escape hatch, such as git --no-alias COMMAND, and it should probably only apply to porcelains.

Thoughts?

j.

Heya,

On Fri, Mar 6, 2009 at 23:30, Jay Soffian <jaysoffian@gmail.com> wrote:

Hmmm, maybe we could require marking such an alias somehow, to signify that you're aware that you're overriding a builtin? Also, what would we do the alias 'foo' calling 'git foo'? Does it call the original command, or itself?

Jay Soffian <jaysoffian@gmail.com> writes:

It is not.

Because sane shells do not expand aliases when used in a script, and gives a handy way to defeat the alias even from the command line.

    $ alias ls='ls -aF'
    $ echo ls >script
    $ chmod +x script

and compare:

    $ ./script
    $ ls
    $ /bin/ls

On Fri, Mar 6, 2009 at 6:22 PM, Junio C Hamano <gitster@pobox.com> wrote:

Understood. And if git could do the same, still no?

j.

Hi,

On Fri, 6 Mar 2009, Jay Soffian wrote:

What you dream about breaks a lot of scripts.

So while it might be nice for you, you would make life of others much, much, much harder. Not nice at all.

Ciao, Dscho

On Fri, Mar 6, 2009 at 9:37 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

I said I understood the implications.

This is not something I am dreaming about, and I'm only interested to the extent that it improves git w/o hindering existing users. I'm certainly not aiming to be not nice to anyone!

For example, what if:

1. The aliases applied only to porcelain commands, not to plumbing.
2. The aliases worked only if stdout was a terminal, using the same
method that git uses for detecting when it is okay to start a pager.
3. git took --alias-builtins and --no-alias-builtins just like it
takes --paginate and --no-pager to override (2).

j.

Hi,

On Fri, 6 Mar 2009, Jay Soffian wrote:

Inconsistency like this is bad for a couple of reasons. Just 3 out of them:

- it makes it hard for users to understand,

- it is prone for subtle breakages,

- the code will be complicated, and therefore ugly.

This would be even more complicated to understand for the regular Git user who just wants to use the darned thing and not care about its internals.

And this makes it even more complicated.

I'd rather stay with our current notion that aliases cannot override Git programs. This is _very_ easy to explain, and also _very_ easy to defend.

Ciao, Dscho