Most subcommands are written in C or shell. A few are written in
Perl.
While we strongly encourage coding in portable C for portability,
these specific scripting languages are also acceptable. We won’t
accept more without a very strong technical case, as we don’t want
to broaden the Git suite’s required dependencies. Import utilities,
surgical tools, remote helpers and other code at the edges of the
Git suite are more lenient and we allow Python (and even Tcl/tk),
but they should not be used for core functions.
This may change in the future. Especially Python is not allowed in
core because we need better Python integration in the Git Windows
installer before we can be confident people in that environment
won’t experience an unacceptably large loss of capability.
C commands are normally written as single modules, named after the
command, that link a collection of functions called libgit. Thus,
your command git-foo would normally be implemented as a single
"git-foo.c" (or "builtin/foo.c" if it is to be linked to the main
binary); this organization makes it easy for people reading the code
to find things.
See the CodingGuidelines document for other guidance on what we consider
good practice in C and shell, and api-builtin.txt for the support
functions available to built-in commands written in C.