Re: [PATCH v3] build: add default aliases

[Michael Haggerty <mhagger@alum.mit.edu>]

On 09/29/2013 12:41 AM, Felipe Contreras wrote:
> On Tue, Sep 24, 2013 at 1:39 PM, Jonathan Nieder <jrnieder@gmail.com> 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
>>>
>>> [...]
> 
>> But making 'ci' a synonym of another command by default while still
>> keeping its definition configurable would be doing people a
>> disservice, I fear.
> 
> And I and many (most) users disagree.
> 
>> 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.

...and in scripts.

> It might, or...
> 
>> 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.
> 
> Precisely for this reason it might not. If people know aliases can be
> different in different machines, they would avoid them in
> documentation which is meant for all machines.

My experience contradicts your prediction.  I have 'ci'/'co' aliases in
my own configuration.  But even though I am aware of the fact that other
people might not have the same aliases, I have on multiple occasions
used them in documentation and/or scripts meant for other people.  The
muscle memory is just too strong.

My error was discovered by other people who didn't have those aliases.
If *most* people had the same aliases as I did, and others had defined
their own slightly different ones, then the scripts would have subtly
malfunctioned for the latter set of users and I would have had trouble
reproducing the errors.

That being said, independent of aliases, there are many other config
settings that can affect commands that might be used in documentation or
scripts, and which also could be the source of errors for the non-vigilent.

So, even though I think such aliases are a great convenience factor, I
am -0 on including pre-defined but overrideable aliases and -1 on
including pre-defined and non-overrideable aliases.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/