7 There are 4 things to do to add a built-in command implementation to
10 . Define the implementation of the built-in command `foo` with
13 int cmd_foo(int argc, const char **argv, const char *prefix);
15 . Add the external declaration for the function to `builtin.h`.
17 . Add the command to the `commands[]` table defined in `git.c`.
18 The entry should look like:
20 { "foo", cmd_foo, <options> },
22 where options is the bitwise-or of:
25 If there is not a Git directory to work on, abort. If there
26 is a work tree, chdir to the top of it if the command was
27 invoked in a subdirectory. If there is no work tree, no
31 If there is a Git directory, chdir as per RUN_SETUP, otherwise,
36 If the standard output is connected to a tty, spawn a pager and
37 feed our output to it.
41 Make sure there is a work tree, i.e. the command cannot act
43 This only makes sense when `RUN_SETUP` is also set.
45 . Add `builtin/foo.o` to `BUILTIN_OBJS` in `Makefile`.
47 Additionally, if `foo` is a new command, there are 3 more things to do:
49 . Add tests to `t/` directory.
51 . Write documentation in `Documentation/git-foo.txt`.
53 . Add an entry for `git-foo` to `command-list.txt`.
55 . Add an entry for `/git-foo` to `.gitignore`.
58 How a built-in is called
59 ------------------------
61 The implementation `cmd_foo()` takes three parameters, `argc`, `argv,
62 and `prefix`. The first two are similar to what `main()` of a
63 standalone command would be called with.
65 When `RUN_SETUP` is specified in the `commands[]` table, and when you
66 were started from a subdirectory of the work tree, `cmd_foo()` is called
67 after chdir(2) to the top of the work tree, and `prefix` gets the path
68 to the subdirectory the command started from. This allows you to
69 convert a user-supplied pathname (typically relative to that directory)
70 to a pathname relative to the top of the work tree.
72 The return value from `cmd_foo()` becomes the exit status of the