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 [off-list ref] 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

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

On Fri, Mar 6, 2009 at 9:37 PM, Johannes Schindelin
[off-list ref] 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.

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