Subject: Allow git alias to override existing Git commands

From: Jeremy Morton <[email-masked]>
Date: Tue, 10 Nov 2015 16:31:21 +0000

It's recently come to my attention that the "git alias" config 
functionality ignores all aliases that would override existing Git 
commands.  This seems like a bad idea to me.

For example, I wanted to setup "git clone" to automatically act as 
"git clone --recursive".  Sure I could do it in the shell, but it's 
more of a pain - any tutorial I set up about doing it would have to 
worry about what shell the user was using - and if you're going to 
make that argument, why have "git alias" at all?  It can all be done 
from the shell.

Obviously I could also use a different alias that wasn't an existing 
Git command for this behaviour, but that would rather defeat the 
point: I want "git clone" to have different functionality.  If I 
remembered to use a different Git command, I might as well remember to 
type "git clone --recursive".  Also, if a future Git command were 
introduced with the same name as my alias, my alias's functionality 
would suddenly be ignored, giving unexpected behaviour.

The reasoning behind this that it's "to avoid confusion and troubles 
with script usage" seems to be at odds with the general Git mentality 
that the user is given lots of power, and if they screw it up it's 
basically just user error.  For example, Git doesn't *have* to allow 
you to rebase.  It's a potentially dangerous operation, so why is it 
allowed?  It might "cause confusion and troubles".

On the other hand, by disallowing the overriding of existing Git 
commands through aliases you are preventing a lot of useful 
functionality that those aliases might be used for.

So I think you should either allow Git aliases to override existing 
Git commands by default, or at least provide a config option that 
allows the user to say that this should happen.

-- 
Best regards,
Jeremy Morton (Jez)