1From: Eric S. Raymond <esr@thyrsus.com> 2Abstract: This is how-to documentation for people who want to add extension 3 commands to Git. It should be read alongside api-builtin.txt. 4Content-type: text/asciidoc 5 6How to integrate new subcommands 7================================ 8 9This is how-to documentation for people who want to add extension 10commands to Git. It should be read alongside api-builtin.txt. 11 12Runtime environment 13------------------- 14 15Git subcommands are standalone executables that live in the Git exec 16path, normally /usr/lib/git-core. The git executable itself is a 17thin wrapper that knows where the subcommands live, and runs them by 18passing command-line arguments to them. 19 20(If "git foo" is not found in the Git exec path, the wrapper 21will look in the rest of your $PATH for it. Thus, it's possible 22to write local Git extensions that don't live in system space.) 23 24Implementation languages 25------------------------ 26 27Most subcommands are written in C or shell. A few are written in 28Perl. 29 30While we strongly encourage coding in portable C for portability, 31these specific scripting languages are also acceptable. We won't 32accept more without a very strong technical case, as we don't want 33to broaden the Git suite's required dependencies. Import utilities, 34surgical tools, remote helpers and other code at the edges of the 35Git suite are more lenient and we allow Python (and even Tcl/tk), 36but they should not be used for core functions. 37 38This may change in the future. Especially Python is not allowed in 39core because we need better Python integration in the Git Windows 40installer before we can be confident people in that environment 41won't experience an unacceptably large loss of capability. 42 43C commands are normally written as single modules, named after the 44command, that link a collection of functions called libgit. Thus, 45your command 'git-foo' would normally be implemented as a single 46"git-foo.c" (or "builtin/foo.c" if it is to be linked to the main 47binary); this organization makes it easy for people reading the code 48to find things. 49 50See the CodingGuidelines document for other guidance on what we consider 51good practice in C and shell, and api-builtin.txt for the support 52functions available to built-in commands written in C. 53 54What every extension command needs 55---------------------------------- 56 57You must have a man page, written in asciidoc (this is what Git help 58followed by your subcommand name will display). Be aware that there is 59a local asciidoc configuration and macros which you should use. It's 60often helpful to start by cloning an existing page and replacing the 61text content. 62 63You must have a test, written to report in TAP (Test Anything Protocol). 64Tests are executables (usually shell scripts) that live in the 't' 65subdirectory of the tree. Each test name begins with 't' and a sequence 66number that controls where in the test sequence it will be executed; 67conventionally the rest of the name stem is that of the command 68being tested. 69 70Read the file t/README to learn more about the conventions to be used 71in writing tests, and the test support library. 72 73Integrating a command 74--------------------- 75 76Here are the things you need to do when you want to merge a new 77subcommand into the Git tree. 78 791. Don't forget to sign off your patch! 80 812. Append your command name to one of the variables BUILTIN_OBJS, 82EXTRA_PROGRAMS, SCRIPT_SH, SCRIPT_PERL or SCRIPT_PYTHON. 83 843. Drop its test in the t directory. 85 864. If your command is implemented in an interpreted language with a 87p-code intermediate form, make sure .gitignore in the main directory 88includes a pattern entry that ignores such files. Python .pyc and 89.pyo files will already be covered. 90 915. If your command has any dependency on a particular version of 92your language, document it in the INSTALL file. 93 946. There is a file command-list.txt in the distribution main directory 95that categorizes commands by type, so they can be listed in appropriate 96subsections in the documentation's summary command list. Add an entry 97for yours. To understand the categories, look at command-list.txt 98in the main directory. If the new command is part of the typical Git 99workflow and you believe it common enough to be mentioned in 'git help', 100map this command to a common group in the column [common]. 101 1027. Give the maintainer one paragraph to include in the RelNotes file 103to describe the new feature; a good place to do so is in the cover 104letter [PATCH 0/n]. 105 106That's all there is to it.