allowing aliases to override builtins to support default options

allowing aliases to override builtins to support default options

[Jay Soffian]

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.

Re: allowing aliases to override builtins to support default options

[Sverre Rabbelier]

Heya,

On Fri, Mar 6, 2009 at 23:30, Jay Soffian <jaysoffian@gmail.com> wrote:
> 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...)

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?

-- 
Cheers,

Sverre Rabbelier

Re: allowing aliases to override builtins to support default options

[Junio C Hamano]

Jay Soffian <jaysoffian@gmail.com> writes:

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

It is not.

> Most shells support overriding commands with aliases, and I'm not sure
> why git needs to be more conservative than the shell.

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

Re: allowing aliases to override builtins to support default options

[Jay Soffian]

On Fri, Mar 6, 2009 at 6:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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

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

j.

Re: allowing aliases to override builtins to support default options

[Johannes Schindelin]

Hi,

On Fri, 6 Mar 2009, Jay Soffian wrote:

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

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

Re: allowing aliases to override builtins to support default options

[Jay Soffian]

On Fri, Mar 6, 2009 at 9:37 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> What you dream about breaks a lot of scripts.

I said I understood the implications.

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

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.

Re: allowing aliases to override builtins to support default options

[Johannes Schindelin]

Hi,

On Fri, 6 Mar 2009, Jay Soffian wrote:

> For example, what if:
> 
> 1. The aliases applied only to porcelain commands, not to plumbing.

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.

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

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.

> 3. git took --alias-builtins and --no-alias-builtins just like it takes 
>    --paginate and --no-pager to override (2).

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