Git Rev News: Edition 120 (February 28th, 2025)

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.

Discussions

Reviews

  • [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.

Community Spotlight: Chris Torek

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?

Other News

Various

Light reading

Git tools and sites

Releases

Credits

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.