Allow git alias to override existing Git commands

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.