Welcome to the 120th 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 January and February 2025.
[PATCH] worktree: detect from secondary worktree if main worktree is bare
Last November, Olga Pilipenco sent a patch to the mailing list addressing an issue she had encountered while working with multiple worktrees.
Git worktrees allow developers to check out multiple branches from the same repository simultaneously, each in its own working directory. Unlike creating separate clones, worktrees share the same object database and references, saving disk space and avoiding the need to push and fetch between copies of the repository. They can be very useful when working on multiple features in parallel or when needing to make a quick fix while in the middle of other development work.
The issue happened when a repository had a main worktree that was
bare with core.bare = true in config.worktree. After creation of a new
secondary worktree, from that secondary worktree’s point-of-view
the main worktree appeared as non-bare. This prevented users from
checking out or working with the default branch of the main worktree
(typically “main” or “master”) in the secondary worktree.
When extensions.worktreeConfig is enabled, each worktree has its
own configuration settings in a config.worktree file that can
override repository-wide settings in the common config file. This
allows different worktrees to have different configurations, but it
also means that settings from one worktree aren’t automatically
visible to commands running in another worktree.
Olga found that when inside the secondary worktree, the main
worktree’s configuration wasn’t initialized, and her patch fixed
that by loading the main worktree’s config.worktree file only when
required.
Unfortunately Olga’s email fell through the cracks, receiving no response. But last January she sent a version 2 of her patch. There was no code change compared to the first version, but she added people in “Cc:”, and she had rebased the patch on top of the “maint” branch.
This time Eric Sunshine replied. He acknowledged that this was a real problem and noted that it had been documented in a “NEEDSWORK” comment added in 2019 to the code which now got patched. He then attempted to rewrite the commit message of the patch in a way that was “more idiomatic” to the project and that added more details to help understand the problem.
The suggested commit message especially mentioned that when
extensions.worktreeConfig is true, commands run in a secondary
worktree only consulted $commondir/config and
$commondir/worktrees/<id>/config.worktree. Thus they never saw
that the main worktree’s core.bare setting was true in
$commondir/config.worktree.
Eric also suggested removing some parts of Olga’s commit message that talked about other solutions she had considered, or repeated in which circumstances the problem appeared. Finally, there were a number of small comments on the code part of the patch.
Olga replied to Eric saying that the commit message he proposed was “so much better” than the original one. She agreed with most of Eric’s suggestions and answered the few questions he asked.
Eric replied explaining some technical details and making a few more suggestions.
Junio Hamano, the Git maintainer, then replied to Eric thanking him “for an easy-to-read review” and thanking Olga for working on this issue.
Eric and Olga further discussed technical improvements to the patch. In the course of that discussion, Eric explained the historical context related to using the “bare main worktree” expression:
It’s a historic “accident” that when worktree support was designed, the idea of linking worktrees to a bare repository was not considered. Support for using worktrees with a bare repository was added later. However, by that time, the term “main worktree” was already well established, with the very unfortunate result that even when there is no actual “main worktree” but only a bare repository with “linked worktrees” hanging off it, the repository itself is usually referred to as the “bare main worktree”, which is an obvious misnomer; the repository is just a repository (i.e. the object database and other meta-information) and there is no actual main worktree.
Olga then sent a version 3 of her patch. It used the commit message suggested by Eric, and implemented his suggestions.
Junio reviewed this new version of the patch and had a single
question about the code that decided when it was necessary to read
the main worktree’s config.worktree file. Olga and Junio further
discussed how to make it clearer what that code was doing, and
eventually agreed on adding a four line long comment on top of it.
Olga then sent a version 4 of her patch which only added that four line long comment.
The patch was later merged into the ‘master’ branch, so version 2.49 of Git, which should be released in a few weeks, will finally resolve a long-standing issue and significantly enhance the usability of Git worktrees for developers working with bare repositories.
Chris Torek has been a prolific contributor to the Git topic on Stack Overflow. This edition features an interview with him. This is a continuation of our initiative to interview community contributors outside of our mailing list. Our first interview was with VonC in edition 106.
Who are you and what do you do?
“Who am I” is way too complicated! 🙂 What I do … well, I’m now retired, and you’d think that would give me more time to answer things like this.
I used to do a lot of embedded systems programming, and a lot of internal company education at times (about programming languages, various hardware functions and limitations, software tools, and such). That’s what led me to answering Stack Overflow questions.
What would you name your most important contribution to Git?
I haven’t put much into Git itself. I fixed a minor issue with
case-insensitive rename once, and something that was annoying me about
git diff applied to merge commits [ref].
What was your motivation behind answering questions about Git on Stack Overflow?
Here, well, I got roped into explaining Git to a group that was moving from Mercurial. I found existing descriptions to be lacking. Eventually that particular job went away but the question-answering persisted, until I got sufficiently annoyed at Stack Overflow itself (for various reasons) to take a break that continues to this day.
If you could get a team of expert developers to work full time on something in Git for a full year, what would it be?
I’m not entirely sure. There are a few big issues today, such as
dealing with OS irregularities (the fact that Windows can’t name a
file aux.h for instance is a trivial example of the overall problem;
very long file names, case and UTF-8 encoding sensitivities are
another example of the same underlying issue); the ongoing
transition from SHA-1 to SHA-256
(which works now but there’s no cross-compatibility); a number
of minor but sometimes important niggles with merging; support
for extremely large code bases, including submodules and other
ideas (Microsoft’s Git VFS). I have no ideas for how to
achieve this but a better way to “see” history would,
I think, be a huge improvement.
One other thing that might be particularly good is an equivalent of
Mercurial’s evolve extension.
But even Mercurial’s was never mainstreamed; this is very hard to
get right (whatever “right” means).
If you could remove something from Git without worrying about backwards compatibility, what would it be?
I’m not convinced anything needs to be removed, but it would
simplify things a lot if we didn’t need SHA-1 compatibility, if
SHA-256 magically just worked and everything were converted over. (And
looking at VonC’s reply
I agree that switch+restore is a much better
split than the old checkout.) And, although people like it for
convenience, it might be OK if we all had to use separate
fetch-then-(whatever is needed) steps: see below.
What is your favorite Git-related tool/library, outside of Git itself?
I don’t think I have one. I’ve used gitk for history browsing, and if it were somehow improved (see the list of items above) it might be particularly useful.
What is one of your most favourite features of Git?
Speed. Having used the previous generations of version control (and waited, and waited…), there’s nothing quite like doing an update and having it take only seconds. The distributed nature is also pretty crucial, though it has its pluses and minuses.
Could you brief a bit about one of your most memorable experiences with Git?
Hah, the most memorable one was probably one of the worst, back in the
days of Git 1.5 or so. Back then, an initial git pull wasn’t always
careful about a pre-populated working tree. I had it destroy a week’s
worth of code once. Ever since then I’ve separated pull into fetch
followed by merge-or-rebase. This is long since fixed, but it’s
instructive to new users to know that pull is really two separate
steps. When I started, I didn’t know that: the tutorial I read just
said to run git pull.
What is your advice for people who want to start using Git? Where and how should they start?
I’m not entirely fond of any of the introductions I’ve seen. I started on a book once (between jobs) but stalled out when I went to work for another startup. One of these days I plan to get back to it.
There’s a common conception that “Git is confusing”. What are your thoughts about the same?
There are confusing parts, but they are inherent to the issues that occur with distributed repositories and independent development. The only way to really understand this is to get a good grounding—hence the idea of writing a book.
If there’s one tip you would like to share with other Git developers, what would it be?
For developers in particular, they should probably have a look at what surprises Git users. If something didn’t work the way someone expected it to, why? Was it an incorrect expectation (it probably was) and if so, why did the user have that expectation in the first place?
Various
Light reading
git config options
by Julia Evans on her blog, which was mentioned in Git Rev News Edition #108.git range-diff
by Scott Chacon on GitButler Blog.includeIf, a short post by Matteo Pampana on Medium.com.Git tools and sites
jj), a Git-compatible version control system,
written in Rust, was first mentioned in Git Rev News Edition #85.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 Chris Torek, Štěpán Němec, Bruno Brito and Brandon Pugh.