Welcome to the 118th edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on git.github.io.
This edition covers what happened during the months of November and December 2024.
Git participates in Outreachy’s December 2024 to March 2025 round:
Seyi Kuforiji is working on the “Convert unit tests to use the clar testing framework” project. He is mentored by Patrick Steinhardt and Phillip Wood and posting updates on his gitlab.io blog while his work is on his GitHub repository.
Usman Akinyemi is working on the “Finish adding an ‘os-version’ capability to Git protocol v2” project. He is mentored by Christian Couder and posting updates on his hashnode.dev blog while his work is on his GitLab repository.
Congratulations to Usman and Seyi for being selected!
Thanks to GitHub for funding these two Outreachy internships!
Many thanks also to the other contributors who applied and worked on micro-projects, but couldn’t be selected! We hope to continue to see you in the community!
./configure fails to link test program due to missing dependencies
Last September Henrik Holst reported an issue when trying to compile
Git 2.44.0 with HTTPS/curl support on LFS 12.1. The configure script
failed to detect libcurl’s dependencies properly when trying to link
statically.
The issue occurred because the configure script only used the
-lcurl build flag without running pkg-config --libs libcurl to
add build flags for dependencies like zstd that libcurl
needs. Henrik found that manually setting the LDFLAGS environment
variable to include build flags for all dependencies (like -lcurl
-lssl -lcrypto -lzstd -lbrotlidec -lz) allowed the build to
succeed. This sparked a broader discussion about Git’s build system
situation.
Looking at configure.ac, Junio Hamano, the Git maintainer, noted
that pkg-config isn’t used at all, instead curl-config --libs is
used to detect curl’s flags. Even though the configure script was
added early in the history of the Git project, Junio said it was an
afterthought and nobody has considered “upgrading” from
curl-config to pkg-config for dependency detection.
In fact, our own Jakub Narębski
initially added the configure script
back in 2006 to make it much easier to create the RPM spec file for Git.
Creating *.spec files is especially easy when the
compilation follows traditional configure && make && make install
steps.
brian m. carlson replied to Junio that users shouldn’t statically link libcurl or OpenSSL at all, as this creates security issues. With static linking, security updates to these libraries would require recompiling Git to take effect. In contrast, dynamic linking allows security updates to be applied as soon as a new Git process is spawned.
Patrick Steinhardt replied to Junio suggesting it might be time to reconsider Git’s three build systems (GNU Make, Autoconf, and CMake). He proposed potentially dropping Autoconf and making CMake officially supported, or switching to Meson as an alternative.
CMake was added more recently in 2020 by Sibi Siddharthan as the third build system with the main goal of improving the build experience for developers on Windows.
Soon after Patrick’s reply, the Git Contributors’ Summit took place, and the “Modern Build System” topic was discussed there. Patrick Steinhardt raised concerns about maintaining three different build systems while others were concerned about having good platform support and good Windows developer experience. This led to an extensive discussion about the merits of different build systems in the thread started by Henrik.
Eli Schwartz, the Meson maintainer, made a detailed case for preferring Meson over CMake, citing various CMake pain points and limitations. Phillip Wood agreed with Patrick about getting rid of Autoconf, but raised the importance of Visual Studio integration, since CMake was originally added to improve the Windows developer experience. Johannes Schindelin, alias Dscho, emphasized that CMake’s deep Visual Studio integration was crucial for Windows developers and cautioned against switching to alternatives that would make the Windows experience worse. It appeared that Visual Studio has Meson support via plugins though, which alleviated some concerns.
Paul Smith, the GNU Make maintainer, noted that requiring additional build tools like Meson, which are not yet often used and require some other dependencies, like Python3 for Meson, adds friction, though he acknowledged that for Git specifically this may be less of a concern given its existing dependencies.
Junio seemed to agree that adding support for a fourth build system would be worth it if it would allow the project to drop all other three build systems eventually. He said the new build system would have “to be something available widely and easy to learn”.
Patrick came up later in October with a 21 patch long RFC series to add support for the Meson build system with the goal of eventually replacing the current three build systems.
There were a number of iterations on that series. Among the many comments, Taylor Blau asked about the eventual goals of the series and plans for CMake support. He noted that CMake support in contrib/ was in an awkward position, neither fully supported nor properly maintained out-of-tree. He was concerned about having to maintain three build systems simultaneously during any transition period.
David Aguilar expressed concerns about Python being a dependency through Meson. Eli replied that muon, a C99 implementation of Meson, could be used instead and demonstrated it working with Git’s build.
Jeff King, alias Peff, asked about reliability for bisecting and whether out-of-source builds would work correctly when moving between commits. He also requested better documentation of common developer workflows with Meson compared to Make.
Junio discussed the need to maintain build system compatibility during any transition period. He noted that many of the Makefile options were added over time for good reasons and dropping support for them would need careful consideration.
A number of other developers participated in the reviews. Ramsay Jones tested the patches on various platforms including Cygwin. Phillip Wood reviewed CMake-related changes and provided technical feedback. Johannes Sixt commented on changes to the gitk-git subtree. Eric Sunshine provided technical feedback. Your own Christian Couder provided feedback on the documentation.
Over the iterations, Patrick updated the series to improve documentation, fix conflicts with in-flight patches, and address the various technical concerns raised during review.
Eventually version 11 of the patch series was merged and will be part of Git v2.48.0 that should be released in the next few weeks. It should be a properly supported modern build system that can be faster and more easily configurable than the three existing ones, which will hopefully get deprecated over time.
The merged patch series especially adds
some documentation
(via comments in meson.build)
to help build Git with Meson and
a build system comparison
(in Documentation/technical/build-systems.txt)
that might be interesting to read.
Various
.git directories of private repositories).Light reading
--format=reference).git maintenance command
was mentioned in Git Tips 2: Some Subtle New Things
article on GitButler Blog by Scott Chacon, which in turn was mentioned in
Git Rev News Edition #108.git-imerge was first mentioned in passing in Git Rev News Edition #17,
while Edition #34 includes Developer Spotlight: Michael Haggerty,
an interview with the author of this tool.jj), a Git-compatible version control system,
written in Rust, was first mentioned in
Git Rev News Edition #85.GitFlow: A successful Git branching model
was a blog post by Vincent Driessen from 2010, with a note of reflection from 2020;
the original author now suggests adopting a much simpler workflow (like
GitHub flow) if the team is doing
continuous delivery of software, and using GitFlow only when necessary,
for explicitly versioned software - with multiple versions of it in the wild to be supported.
See also Patterns for Managing Source Code Branches
by Martin Fowler, mentioned in Git Rev News Edition #63.
Git tools and sites
pip.
You can see its demo at http://klausdemo.lophus.org/.
Written in Python, under an unnamed custom permissive license.This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Jakub Narębski <jnareb@gmail.com>, Markus Jansen <mja@jansen-preisler.de> and Kaartic Sivaraam <kaartic.sivaraam@gmail.com> with help from Štěpán Němec.