Re: [PATCH v3] build: add default aliases

[Jonathan Nieder <jrnieder@gmail.com>]

Jeff King wrote:
> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:

>> For now simply add a few common aliases.
>>
>>   co = checkout
>>   ci = commit
>>   rb = rebase
>>   st = status
>
> Are these the best definitions of those shortcuts? It seems[1] that some
> people define "ci" as "commit -a", and some people define "st" as
> "status -s" or even "status -sb".

I feel bad about having waited for 4 rounds of this patch to say this,
but the basic change (providing "co", "ci", etc. as aliases by
default) does not look well thought through.

It would be a different story if this were a patch to update
documentation to suggest adding such aliases at the same time as
telling Git what your name is.  The user manual doesn't explain how to
set up aliases at all yet, and that should be fixed.

But making 'ci' a synonym of another command by default while still
keeping its definition configurable would be doing people a
disservice, I fear.  As long as 'ci' works out of the box, it will
start showing up in examples and used in suggestions over IRC, etc,
which is great.  Unfortunately that means that anyone who has 'ci'
defined to mean something different can no longer use those examples,
that advice from IRC, and so on.  So in the world where 'ci' is a
synonym for 'commit' by default, while people still *can* redefine
'ci' to include whatever options they like (e.g., "-a"), actually
carrying out such a personal customization is asking for trouble.

Incidentally, that is also the reason git already doesn't allow
aliases to override built-in commands such as "git commit", even
though it would be convenient to some to not have to remember to add
"-a" each time.  As consolation we have been able to say "But you can
take the even shorter-and-sweeter 'git ci' and make it mean whatever
you want".  Now we should take that avenue away for people?

Bad idea.

Hope that helps,
Jonathan