Keith Packard, a well-known X.org hacker, describes his reasons for choosing Git as a version control system for X.org.
X.org uses mostly centralized development style, and Git lets you continue working that way:
[…]it all depends on the conventions used within a project and individual developer style.According to Keith, Git also adds several useful features, thanks to its completely distributed origin, and to the format of its repository:
At X.org, we migrated from CVS to Git and yet have retained our largely centralized development model. There are few people publishing alternate trees, and we grant direct repository access to the same set of developers who used to have CVS access.
- Offline repository access. You can have your private repository on e.g. your laptop, and do some development work in offline mode. You commit as often as needed, saving your entire history in arbitrary level of details. When you are back online, you can push your private repository to the public repository, and all your changes almost smoothly go to there, with entire history preserved.
- Private branches. Some developers could have really secret development efforts based on some public codebase (like drivers for the hardware that is not yet released).
Git makes this supremely easy by allowing us to keep the ultra-secret new hardware changes in a private repository while still tracking the public repository. When we’re allowed to release the source code for the new hardware, we simply merge the private branch to the upstream master and push that to the public repository. All of the development history for the new hardware then becomes a part of the public source repository.
- Distributed backups. With Git, when you clone the public repository, you get it in its entirety. Thus, every developer could have a backup copy of repository, immediately available in case something happens to central server. Also, because of the cryptographic protection of repository objects, you can be sure that backup repository was not altered in any way – the checksums just won’t match.
One interesting piece of information is repository size for large projects. It turns out that Git has very low overhead:
The Mozilla CVS repository was 2.7GB, imported to Subversion it grew to 8.2GB. Under Git, it shrunk to 450MB. Given that a Mozilla checkout is around 350MB, it’s fairly nice to have the whole project history (from 1998) in only slightly more space. (Similar numbers are reported in Tracking CVS repository with Git).