| builtin API |
| =========== |
| |
| Adding a new built-in |
| --------------------- |
| |
| There are 4 things to do to add a built-in command implementation to |
| Git: |
| |
| . Define the implementation of the built-in command `foo` with |
| signature: |
| |
| int cmd_foo(int argc, const char **argv, const char *prefix); |
| |
| . Add the external declaration for the function to `builtin.h`. |
| |
| . Add the command to the `commands[]` table defined in `git.c`. |
| The entry should look like: |
| |
| { "foo", cmd_foo, <options> }, |
| + |
| where options is the bitwise-or of: |
| |
| `RUN_SETUP`:: |
| If there is not a Git directory to work on, abort. If there |
| is a work tree, chdir to the top of it if the command was |
| invoked in a subdirectory. If there is no work tree, no |
| chdir() is done. |
| |
| `RUN_SETUP_GENTLY`:: |
| If there is a Git directory, chdir as per RUN_SETUP, otherwise, |
| don't chdir anywhere. |
| |
| `USE_PAGER`:: |
| |
| If the standard output is connected to a tty, spawn a pager and |
| feed our output to it. |
| |
| `NEED_WORK_TREE`:: |
| |
| Make sure there is a work tree, i.e. the command cannot act |
| on bare repositories. |
| This only makes sense when `RUN_SETUP` is also set. |
| |
| . Add `builtin/foo.o` to `BUILTIN_OBJS` in `Makefile`. |
| |
| Additionally, if `foo` is a new command, there are 3 more things to do: |
| |
| . Add tests to `t/` directory. |
| |
| . Write documentation in `Documentation/git-foo.txt`. |
| |
| . Add an entry for `git-foo` to `command-list.txt`. |
| |
| . Add an entry for `/git-foo` to `.gitignore`. |
| |
| |
| How a built-in is called |
| ------------------------ |
| |
| The implementation `cmd_foo()` takes three parameters, `argc`, `argv, |
| and `prefix`. The first two are similar to what `main()` of a |
| standalone command would be called with. |
| |
| When `RUN_SETUP` is specified in the `commands[]` table, and when you |
| were started from a subdirectory of the work tree, `cmd_foo()` is called |
| after chdir(2) to the top of the work tree, and `prefix` gets the path |
| to the subdirectory the command started from. This allows you to |
| convert a user-supplied pathname (typically relative to that directory) |
| to a pathname relative to the top of the work tree. |
| |
| The return value from `cmd_foo()` becomes the exit status of the |
| command. |