Any reason to use a Git alias instead of a git-* s

Question

In Git, you can create custom commands using either an alias or by creating an executable file, included in your PATH, starting with git-. Is there any reason to choose an alias as opposed to a script?

I work with a team of developers and have made some handy aliases I'd like to share with them. A colleague of mine suggested that aliases should be used for simple things, like shortening a command (e.g. git co as an alias for git checkout), and that scripts would be useful for more complicated tasks, like combining multiple functions into one. But he couldn't come up with any reason why not to use scripts, not sure if it's just how he felt it should be, or if he had heard somewhere that that's how it should be, or what.

Our team all works on the same development server, so if I can use a script, I can simply put it in /usr/local/bin and everyone will have access to it automatically. So even with a simple alias, it would be much more convenient to just have it as a git script so that everyone automatically has it, as opposed to me having to tell everyone to set it up individually. Not to mention, when a new developer starts, we would have to remember to have them set it up as well.

I know it sounds like I'm campaigning for the script approach, and I am. I'm just wondering if there is any drawback to using that approach.

Answer 1

With using git aliases you will be able to use autocompletion of branch names, tags, etc

Answer 2

Aliases are defined via git's config mechanism, so they can apply to either the whole system, a single user, or just a single repository, depending on whether you define them in /etc/gitconfig, ~/.gitconfig or $GIT_DIR/config. If you copy your own .gitconfig to a new machine, it will include all your personal aliases by copying a single file, which seems less overhead than copying a full directory and setting up PATH correctly to find your files.