The git/git mirror turns pull requests into patches, not merges

Contributions arrive as patches on [email protected], not as merges

The repository description says it plainly: this is a publish-only repository, and pull requests can be turned into patches to the mailing list through GitGitGadget, with any improvement expected to follow the Documentation/SubmittingPatches procedure. Nothing lands here because a maintainer pressed a button. A change goes to [email protected], is reviewed on the list, and enters the tree when somebody commits it.

That changes who this repository is for. A fork-and-pull-request workflow stops at the patch; a contributor with no C experience can still read CodingGuidelines and SubmittingPatches, both at Documentation/, and follow the procedure. Two dotfiles beside them, .b4-config and .b4-cover-template, hold the settings and the cover letter template for a patch series, so the submission is an email thread with a subject line and a diff, not a diff view in a browser.

The list is also the status channel. The README says the maintainer frequently sends "What's cooking" reports listing the current status of various development topics, and that the discussion after them is a good reference for project status, direction and remaining tasks. Archives sit at lore.kernel.org/git/ and marc.info, and subscription is an email to [email protected].

Two badges, three pipeline configs, one master branch

The README carries two build badges: one pointing at GitHub Actions filtered to branch master and event push, one pointing at gitlab.com/git-scm/git pipelines for ref master. The tree underneath holds .github/, .gitlab-ci.yml and .cirrus.yml, so a commit to master is expected to satisfy hosted checks in more than one place, and the badge a reader sees first covers only the GitHub Actions side.

For a contributor this is the practical difference between the mirror and a normal repository. Your patch is validated by someone else's infrastructure, and the pipeline definitions are not in the tree in a form you can read at a glance, so when a check fails you are reading the log of a system you do not control. For a distributor it is the opposite: a mirror that is continuously built is a mirror whose breakage is noticed.

Related housekeeping lives in the same root. .mailmap normalises author names and addresses in the history, which is why a git log on this tree shows names that differ from the commits a patch author originally made. .gitattributes and .gitmodules are also present, so the tree declares submodules, and a build that expects a fully self-contained checkout has to account for them.

Unusual platforms are fixed with Makefile defines, not with patches

The Makefile has no detection logic of its own. It includes shared.mak and then documents a list of defines that describe what the operating system will tolerate, most of it auto-detected in config.mak.uname or in configure.ac. The list names SHELL_PATH for a broken /bin/sh, SANE_TOOL_PATH for broken tools in /usr/bin, SOCKLEN_T when system headers lack a socklen_t type, INLINE as a substitute for __inline, SNPRINTF_RETURNS_BOGUS for snprintf that reports failure instead of a length, FREAD_READS_DIRECTORIES for fopen that succeeds on a directory, OPEN_RETURNS_EINTR for a signal that interrupts open, HAVE_ALLOCA_H and HAVE_PATHS_H.

One define has a consequence you should decide deliberately rather than inherit: NO_OPENSSL, documented as the answer for a machine that has no OpenSSL. What the file does not enumerate is what the build gives up when that define is set, so anyone compiling Git without it has to establish for themselves which TLS path the resulting binary actually has.

For a porter, this is the mechanism the project offers instead of per-platform patches. A host with unusual headers is described by a define list, and a define that does not exist yet becomes a new line in the Makefile with a comment explaining the symptom. That is a much slower path to a working binary than installing a package someone else already built.

The default target skips configure, and the version string is generated at build time

The default target of the Makefile is all::, and the file opens by importing tree-wide behaviour from shared.mak. Configure is optional, described in a comment as the optional "make configure && ./configure" pair and deferred to INSTALL. Version and build options are not written into the source by hand: GIT-VERSION-FILE.in and GIT-BUILD-OPTIONS.in are templates, and GIT-VERSION-GEN is the generator beside them.

If you came here looking for an install command, there is none, and the README says so by pointing at the INSTALL file for installation instructions. What you can reconstruct from the build files is the shape of a build: a plain make for the default target, or the optional pair below if your platform needs the auto-detection that configure.ac performs.

make configure && ./configure

The other half of the build is Rust. Cargo.toml at the root declares a package called gitcore at version 0.1.0, edition 2018, rust-version 1.49.0, with crate-type ["staticlib"] and an empty [dependencies] section. A crate version of 0.1.0 tells you nothing about which Git you built, and crate-type staticlib means the output is a library to link, not a program to run.

One C file per command, with a banned.h keeping the list honest

The tree is flat and named after commands. add-interactive.c, alias.c, apply.c, archive.c with archive-tar.c and archive-zip.c beside it, attr.c, base85.c, bisect.c, blame.c, blob.c, bloom.c, branch.c, abspath.c, add-patch.c, advice.c and alloc.c all sit at the top level, most with a matching .h sidecar, alongside block-sha1/ and the C files for the plumbing behind them. A patch to Git is therefore usually a diff against a file whose name is the command it changes.

Two of those names are worth pausing on. advice.c holds the user-facing text, which is why translation work happens in po/ rather than in the command files, and po/README.md explains that a po file is a Portable Object file holding the translations. banned.h is a header with no command of its own, and its presence in a flat tree of per-command files is a statement about what the code is not allowed to call.

Style is not left to reviewers either. .clang-format and .editorconfig sit at the root next to the code, so a patch that reformats surrounding lines is arguing with a machine. The visible tree is also truncated at branch.c, which means a count of files or a judgement about what is missing from the top level is not something this listing can support.

Licence is GPLv2 plus parts under other licences, and the root says so with files

The README states that Git is covered by the GNU General Public License version 2, with some parts under different licences compatible with GPLv2. It does not itemise which parts, and the repository's own licence metadata comes back as no single identifier, so a reader who needs the exact terms per file has to go to the notices in the tree. Two files at the root are the visible proof that more than one licence is in play: COPYING and LGPL-2.1.

What this means for someone who vendors the source is practical rather than legal. A product that ships Git has to satisfy the GPLv2 obligations and, for the parts under other terms, those terms, and the only complete statement of which is which sits in the files themselves. Nothing in the README shortens that work, and nothing in the repository automates it.

Security reports are handled separately from the patch flow: issues that are security relevant should be disclosed privately to the Git Security mailing list at [email protected], and a SECURITY.md file sits at the root. For an ordinary bug, the route is the same as for any other change, which is the list.

The mirror ships no releases, so it cannot install Git for you

There are no GitHub releases attached to this repository, and no packages. RelNotes sits at the root, so release notes arrive as files in the tree rather than as release objects with attached binaries. The README points to git-scm.com for online resources and Git related tools, which is where a binary for your platform comes from.

The documentation makes the same assumption in passing: if Git has been correctly installed, the tutorial can be read from the terminal like this, and the migration guide for CVS users can be read the same way.

git help tutorial
man gittutorial
man gitcvs-migration
git help cvs-migration

Reading the manual pages depends on having built the binary, and this repository cannot hand you one.

That is the difference in approach between this tree and a distribution package. A package ships a binary configured for a target platform, with the defines already resolved and the version string already generated. Building here means you resolve those defines yourself, using config.mak.uname, configure.ac or the define list in the Makefile. The mirror is worth that effort when you are changing Git or porting it. It is wasted effort when all you wanted was to install a working copy.

Editorial conclusion

Work in this repository when you are porting Git to a platform it does not build on, auditing the implementation, or preparing a patch for the list, because the Makefile defines and the mail-based review flow are the whole point of the tree. Ignore it if you want a working Git binary: the mirror has no releases, no packages and no install command of its own, and the README sends you to the INSTALL file and to git-scm.com for that. Before you start, read INSTALL and check which of the platform defines your system actually needs, because that list, not a patch, is how an unusual build gets fixed.

Frequently asked questions

Official sources

1. Official README
2. Project repository