Re: default aliases (ci, di, st, co)

> Ondrej Certik wrote:
>> Hi,
>>
>> coming to git from mercurial and svn, here is the alias part of my .gitconfig:
>>
>> [alias]
>>     ci = commit
>>     di = diff --color-words
>>     st = status
>>     co = checkout
>>
>>
>> And all is fine until I share commands to checkout my branch (for
>> example) with other people, then basically I have to write those
>> commands in full (e.g. commit, checkout, ...), since I cannot assume
>> they have their .gitconfig setup the same way I do. Especially for
>> people who are new to git.
>>
>> What is the view on this in the git community?
> 
> 
> Personally I think "plain" aliases like you use above are evil.
> git is not svn or mercurial. If you use it like svn you'll be
> surprised sooner or later and your workflow will feel awkward or
> just plain wrong. hg and git are very similar, but the fact that
> hg assumed the svn shorthands implies to me that they've tried
> to retain a compatibility that does not, in fact, exist. DVCS
> systems are enormously different from centralized ones. Borrowing
> from centralized ones to a DVCS one feels utterly backwards.
> 
> 
>> Do most of you write
>>
>> git checkout -b branch ...
>>
>> (possibly with TAB completion) or do most of you write
>>
>> git co -b branch ...
>>
>> (like I do all the time, except when sharing my commands with other people)?
>>
> 
> I have no simple aliases for any of the commands. There's just no reason
> for them since tab completion works so well.
> 
> I do have one alias, which is "wsfix". It fixes whitespace fsckups I've
> added to the index but not yet committed to the worktree. It's not a
> particularly complex one, but not exactly simple either.
> 
> 
>> Could in principle those aliases be even made default by git? Or is
>> this not a good idea.
>>
> 
> I see no reason to add default aliases. It will make a mess of things
> when trying to explain workflows to people who have older versions of
> git where those default aliases aren't available. It'll add complexity
> to explanations, which is never a good thing.
> 
> If I have a vote, I vote no.
>