Friendly forks: long-lived complements, not rivals
When you need major changes to a repository you don’t own, the usual path is to contribute them yourself. That works well when maintainers accept the work. But if a feature is rejected, or was never meant to be merged upstream, a fork may be the better option. A friendly fork is a long-lived fork that complements its upstream repository with customizations for a specific subset of users. Ideally, those customizations flow back upstream through a process called upstreaming, which usually means the fork’s developers maintain an active relationship with upstream maintainers. That relationship isn’t strictly required, however; a friendly fork can simply track upstream releases while keeping its own changes local, and it may or may not eventually re-merge with the original project.
This is in contrast to a divergent fork, which typically results from unresolved community disagreements. Divergent forks tend to drift so far from upstream that sharing code becomes impractical. The rest of this article focuses on friendly forks, using three maintained forks of the git/git repository as examples.
Why fork Git at all?
The git/git project is maintained by experts in Unix systems, which leaves Windows support outside its scope. That reality led to the creation of git-for-windows/git in 2007, the oldest of the three forks discussed here. What was originally intended to be a short-lived effort became permanent as the community’s need for Windows support continued.
The fork serves two main purposes:
- Provide a smooth experience for Windows users.
- Keep a separation of concerns: Windows-specific and Unix-specific features live in different repositories, while shared features can move freely between them.
Features sometimes land in the fork before they go upstream. For example, FS Monitor went through the Request for Comments process on the git/git mailing list, but early implementations were merged into git-for-windows/git for rapid testing.
A fork with broader ambitions
microsoft/git started as a private fork of git-for-windows/git, supporting Microsoft-internal products. It was open-sourced in 2017, and its goals shifted to serve the wider community:
- Enable quick releases of new features so they can be dogfooded by GitHub’s monorepo customers.
- Identify which of those features make sense to upstream, then submit and track them on the mailing list.
The sparse index is a notable example. It was introduced into microsoft/git first, getting the feature into the hands of monorepo customers quickly, and was then gradually refined and introduced upstream.
A private fork that powers a product
github/git did not start as a fork. In GitHub’s early days, custom changes to Git were small enough to store as *.patch files, applied on top of each new release before deployment. As those changes grew in number and in their potential to be contributed back, GitHub created the official fork in 2012 to improve management and workflow.
Unlike the other two forks, github/git is a private friendly fork. That privacy has advantages: it serves as an internal testing ground where code can be battle-tested before being submitted publicly upstream, and it can operate more independently of the upstream release cadence. The fork still powers GitHub’s backend, holding infrastructure-specific changes such as extra instrumentation, and acts as a staging area for features before they are sent to the open source git/git repository. Bitmaps and multi-pack bitmaps both followed this path.
Beyond Git, friendly forks exist elsewhere. MSYS2 is a fork of Cygwin that provides an environment for building and running native Windows software. CentOS, created in 2004, was a fork of Red Hat Enterprise Linux intended to offer a community-oriented RHEL-like experience; Red Hat now owns the CentOS trademarks.
This article has covered what defines a friendly fork and how it differs from a divergent one, along with the purposes behind three long-lived forks of git/git. The next part of this series will look at how these forks are managed and how you can apply those strategies to your own friendly fork.
