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)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html