Extending Git functionality

Question

I was wondering if there was an easy way to extend Git commands.

So I could create commands like:

git my-custom-made-extension --my-options <my-other-arguments>

In a perfect world, I would be able to do it in any language it pleases me and I would be able to add my custom made extensions to any development environment fairly easily.

Let's say, something like the support of plugins in Vim?

Norford

your link is broken -- a quick search didn't turn up any obvious replacements – Simpson

Answer 1

As you can see in the source code in execv_dashed_external, If you make the command git-my-custom-made-extension, then git will alias:

• git my-custom-made-extension ... → git-my-custom-made-extension ...
• git help my-custom-made-extension → man git-my-custom-made-extension

There's nothing special about "extending git". Just build a program as you would normally, and make sure the name starts with git-.

Unblushing

Already explained in my response. Have you some documentation where this is explained in further details? – Norford

I looked, but was having great difficultly finding a reference. – Unblushing

Nice job finding the reference :). – Norford

This didn't work when the command was solely on my path. I had to add my script to /usr/local/bin. – Histolysis

Answer 2

Real life examples

Looking around, there are a lot of projects which extend Git command line:

• git-wtf (written in Ruby) uses brew or manual installation to put an executable in /usr/bin (or was it /usr/local?). And it seems like Git has a mechanism which knows that when you write git wtf it is actually looking for any script in PATH named git-wtf.
• git-annex (written in haskell) has a more complex flavor. But even if it uses Cabal for its installation (and has a long list of dependencies if you don't have it), it seems like its using the same basic principle as git-wtf. (Git will find it in the executable path as you write git annex)
• git-flow (written in shell) uses brew/macport/apt-get/wget+bash to install itself. And, once again, it seems to use the same mechanism.

Solution (?)

So it's certainly possible to write your own custom script and then make it available by placing it in any paths listed in your PATH variable.

But as far as I know, there is a few shortcomings...

Known Issues

The documentation

You are not really extending Git, and so, some commands are not working:

$ git help wtf
No manual entry for git-wtf
$ git wtf --help
No manual entry for git-wtf
$ git wtf -h # the only command which works...
Usage: git wtf [branch+] [options]
...

I didn't try it on git-annex so they may have worked around this issue, but git-flow and git-wtf follow this behavior.

EDIT: git help fallback to the man pages, so this point is sort of unrelated (Thx Eric).

The installation process

Installation by Brew, macports and apt-get are amazing. But there is no globally accepted way of adding features to Git. More specifically, you have no platform independent way of installing your "plugins". Maybe make would do the trick, but even then you would have to write an installation script yourself.

Norford

Are you reading the issue from git help wtf? It says "No manual entry for git-wtf". git help wtf aliases to man git-wtf. – Unblushing

WRT installation, there's no "special trick" for adding features to git. Install your program like you would any other command line tool. – Unblushing

Answer 3

You probably want to create an alias, either manually or with git config. The man page covers this in detail. A really basic example would be something like:

git config --global alias.log1 "log --oneline"

Morbid

I don't want to alias an existing command, but to create a new one. – Norford

@VincentB. the alias can just as well point to a newly created script – Mill