CINXE.COM

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <title>Git Rev News</title> <meta name="viewport" content="width=device-width"> <link rel="icon" type="image/x-icon" href="/images/logo.png"/> <link rel="stylesheet" href="/css/main.css"> <script src="/script/script.js" defer></script> <link rel="alternate" type="application/rss+xml" title="RSS" href="/feed.xml"> </head> <body> <div id="wrapper"> <div id="navbar" class="navbar"> <ul> <li><a href="/">Home</a> <li><a href="/rev_news/rev_news/">About Git Rev News</a> <li><a href="/rev_news/news_sources/">Git Rev News Sources</a> <li><a href="/rev_news/">Git Rev News</a> <li><a href="/rev_news/archive/">Git Rev News Archive</a> <li><a href="/SoC-2025-Microprojects/">SoC 2025 Applicant Microprojects</a> <li><a href="/SoC-2025-Ideas/">SoC 2025 Ideas</a> <li><a href="/SoC-2022-Org-Application/">SoC 2022 Organization Application</a> <li><a href="/Mentoring-Program-Guide/">Mentoring Program Guide</a> <li><a href="/Historical-SoC-Outreachy/">Historical Summer of Code and Outreachy Materials</a> <li><a href="/Hacking-Git/">Hacking Git</a> <li><a href="/General-Microproject-Information/">General Microproject Information</a> <li><a href="/General-Application-Information/">General Application Information</a> <li><a href="/GSoC-Participants/">GSoC participants</a> </ul> </div> <div class="site"> <div class="header">  </div> <h1 id="latest-edition">Latest edition</h1> <article> <div class="post-content"> <h2 id="git-rev-news-edition-120-february-28th-2025">Git Rev News: Edition 120 (February 28th, 2025)</h2> <p>Welcome to the 120th edition of <a href="https://git.github.io/rev_news/rev_news/">Git Rev News</a>, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see <a href="https://git.github.io/rev_news/rev_news/">the Git Rev News page</a> on <a href="http://git.github.io">git.github.io</a>.</p> <p>This edition covers what happened during the months of January and February 2025.</p> <h2 id="discussions">Discussions</h2>  <h3 id="reviews">Reviews</h3> <ul> <li> <p><a href="https://lore.kernel.org/git/pull.1829.git.1731653548549.gitgitgadget@gmail.com/">[PATCH] worktree: detect from secondary worktree if main worktree is bare</a></p> <p>Last November, Olga Pilipenco sent a patch to the mailing list addressing an issue she had encountered while working with multiple <a href="https://git-scm.com/docs/git-worktree">worktrees</a>.</p> <p>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.</p> <p>The issue happened when a repository had a main worktree that was bare with <code class="language-plaintext highlighter-rouge">core.bare = true</code> in <code class="language-plaintext highlighter-rouge">config.worktree</code>. 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.</p> <p>When <code class="language-plaintext highlighter-rouge">extensions.worktreeConfig</code> is enabled, each worktree has its own configuration settings in a <code class="language-plaintext highlighter-rouge">config.worktree</code> file that can override repository-wide settings in the common <code class="language-plaintext highlighter-rouge">config</code> 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.</p> <p>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 <code class="language-plaintext highlighter-rouge">config.worktree</code> file only when required.</p> <p>Unfortunately Olga’s email fell through the cracks, receiving no response. But last January she sent a <a href="https://lore.kernel.org/git/pull.1829.v2.git.1737063335673.gitgitgadget@gmail.com/">version 2</a> 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.</p> <p>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.</p> <p>The suggested commit message especially mentioned that when <code class="language-plaintext highlighter-rouge">extensions.worktreeConfig</code> is true, commands run in a secondary worktree only consulted <code class="language-plaintext highlighter-rouge">$commondir/config</code> and <code class="language-plaintext highlighter-rouge">$commondir/worktrees/<id>/config.worktree</code>. Thus they never saw that the main worktree’s <code class="language-plaintext highlighter-rouge">core.bare</code> setting was true in <code class="language-plaintext highlighter-rouge">$commondir/config.worktree</code>.</p> <p>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.</p> <p>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.</p> <p>Eric replied explaining some technical details and making a few more suggestions.</p> <p>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.</p> <p>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:</p> <blockquote> <p>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.</p> </blockquote> <p>Olga then sent a <a href="https://lore.kernel.org/git/pull.1829.v3.git.1738346881907.gitgitgadget@gmail.com/">version 3</a> of her patch. It used the commit message suggested by Eric, and implemented his suggestions.</p> <p>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 <code class="language-plaintext highlighter-rouge">config.worktree</code> 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.</p> <p>Olga then sent a <a href="https://lore.kernel.org/git/pull.1829.v4.git.1738737014194.gitgitgadget@gmail.com/">version 4</a> of her patch which only added that four line long comment.</p> <p>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.</p> </li> </ul>  <h2 id="community-spotlight-chris-torek">Community Spotlight: Chris Torek</h2> <p><em><a href="https://stackoverflow.com/users/1256452/torek">Chris Torek</a> 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 <a href="https://git.github.io/rev_news/2023/12/31/edition-106/#community-spotlight-vonc">with VonC in edition 106</a></em>.</p> <ul> <li> <p><strong>Who are you and what do you do?</strong></p> <p>“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.</p> <p>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 <a href="https://stackoverflow.com/users/1256452/torek?tab=summary">answering Stack Overflow questions</a>.</p> </li> <li> <p><strong>What would you name your most important contribution to Git?</strong></p> <p>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 <code class="language-plaintext highlighter-rouge">git diff</code> applied to merge commits [<a href="https://public-inbox.org/git/pull.804.v4.git.git.1591978801.gitgitgadget@gmail.com/">ref</a>].</p> </li> <li> <p><strong>What was your motivation behind answering questions about Git on Stack Overflow?</strong></p> <p>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.</p> </li> <li> <p><strong>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?</strong></p> <p>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 <code class="language-plaintext highlighter-rouge">aux.h</code> 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 <a href="https://git-scm.com/docs/hash-function-transition">transition from SHA-1 to SHA-256</a> (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 <em>how</em> to achieve this but a better way to “see” history would, I think, be a huge improvement.</p> <p>One other thing that might be particularly good is an equivalent of <a href="https://www.mercurial-scm.org/doc/evolution/">Mercurial’s <code class="language-plaintext highlighter-rouge">evolve</code> extension</a>. But even Mercurial’s was never mainstreamed; this is very hard to get right (whatever “right” means).</p> </li> <li> <p><strong>If you could remove something from Git without worrying about backwards compatibility, what would it be?</strong></p> <p>I’m not convinced anything needs to be <em>removed</em>, 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 <a href="https://git.github.io/rev_news/2023/12/31/edition-106/#community-spotlight-vonc">VonC’s reply</a> I agree that <code class="language-plaintext highlighter-rouge">switch</code>+<code class="language-plaintext highlighter-rouge">restore</code> is a much better split than the old <code class="language-plaintext highlighter-rouge">checkout</code>.) And, although people like it for convenience, it might be OK if we all had to use separate <code class="language-plaintext highlighter-rouge">fetch</code>-then-(whatever is needed) steps: see below.</p> </li> <li> <p><strong>What is your favorite Git-related tool/library, outside of Git itself?</strong></p> <p>I don’t think I have one. I’ve used <a href="https://git-scm.com/docs/gitk">gitk</a> for history browsing, and if it were somehow improved (see the list of items above) it might be particularly useful.</p> </li> <li> <p><strong>What is one of your most favourite features of Git?</strong></p> <p>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.</p> </li> <li> <p><strong>Could you brief a bit about one of your most memorable experiences with Git?</strong></p> <p>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 <code class="language-plaintext highlighter-rouge">git pull</code> 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 <code class="language-plaintext highlighter-rouge">pull</code> is really two separate steps. When I started, I didn’t know that: the tutorial I read just said to run <code class="language-plaintext highlighter-rouge">git pull</code>.</p> </li> <li> <p><strong>What is your advice for people who want to start using Git? Where and how should they start?</strong></p> <p>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.</p> </li> <li> <p><strong>There’s a common conception that “Git is confusing”. What are your thoughts about the same?</strong></p> <p>There <em>are</em> 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.</p> </li> <li> <p><strong>If there’s one tip you would like to share with other Git developers, what would it be?</strong></p> <p>For <em>developers</em> 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 <em>have</em> that expectation in the first place?</p> </li> </ul> <h2 id="other-news">Other News</h2> <p><strong>Various</strong></p> <ul> <li>The Git project has been accepted as a <a href="https://summerofcode.withgoogle.com/programs/2025/organizations/git">Mentor Organization</a> for Google Summer of Code (GSoC) 2025. We can still add project ideas to our <a href="https://git.github.io/SoC-2025-Ideas/">idea page</a>, and volunteers to (co-)mentor are still welcome. Feel free to join the discussion in the <a href="http://public-inbox.org/git/6C29409D-691B-471F-B08C-83E14D35EE13@gmail.com/T/#mb087c1b0ed06fcbd56d4ffa320efbeb42fd4983f">corresponding thread</a>. Also, feel free to spread the word about Git’s participation.</li> <li><a href="https://github.blog/changelog/2025-02-25-repositories-updated-insight-views-general-availability/">GitHub - Repositories – Updated insight views (General Availability)</a> in GitHub Changelog.</li> </ul> <p><strong>Light reading</strong></p> <ul> <li><a href="https://blog.gitbutler.com/why-is-git-autocorrect-too-fast-for-formula-one-drivers/">Why was Git Autocorrect too fast for Formula One drivers?</a> Why did Git’s autocorrect wait 0.1s before executing a mistyped command? Post by Scott Chacon on GitButler Blog.</li> <li><a href="https://blog.gitbutler.com/how-git-core-devs-configure-git/">How Core Git Developers Configure Git</a> by Scott Chacon on GitButler Blog. <ul> <li>See also <a href="https://jvns.ca/blog/2024/02/16/popular-git-config-options/">Popular <code class="language-plaintext highlighter-rouge">git config</code> options</a> by Julia Evans on her blog, which was mentioned in <a href="https://git.github.io/rev_news/2024/02/29/edition-108/">Git Rev News Edition #108</a>.</li> </ul> </li> <li><a href="https://blog.gitbutler.com/interdiff-review-with-git-range-diff/">How to do patch-based review with <code class="language-plaintext highlighter-rouge">git range-diff</code></a> by Scott Chacon on GitButler Blog.</li> <li><a href="https://www.git-tower.com/blog/asciidoc-quick-guide">Markdown’s Big Brother: Say Hello to AsciiDoc</a> by Marvin Blome on Git-Tower Blog. <ul> <li>Another similar file format for textual data and technical documentation is <a href="https://docutils.sourceforge.io/rst.html">reStructuredText</a> (RST, ReST, or reST). It is used, among others, by the Python programming language community, and is part of the Docutils project of the Python Doc-SIG.</li> </ul> </li> <li><a href="https://www.git-tower.com/blog/trunk-based-development">Understanding the Trunk-Based Development Workflow</a> by Bruno Brito on Git-Tower Blog (2024). <ul> <li>See also the <a href="https://trunkbaseddevelopment.com">https://trunkbaseddevelopment.com</a> site, first mentioned in <a href="https://git.github.io/rev_news/2017/02/22/edition-24/">Git Rev News Edition #24</a>.</li> </ul> </li> <li><a href="https://medium.com/@matteopampana/one-pc-multiple-git-configs-this-will-save-you-time-f702880744f7">One PC, Multiple Git Configs (This Will Save You Time!)</a> with <code class="language-plaintext highlighter-rouge">includeIf</code>, a short post by Matteo Pampana on Medium.com.</li> <li><a href="https://www.itsecurityguru.org/2025/01/27/why-some-source-code-files-shouldnt-be-managed-via-git-based-version-control/">Why Some Source Code Files Shouldn’t Be Managed via Git-Based Version Control</a> on IT Security Guru.</li> <li><a href="https://www.brandonpugh.com/blog/git-stash-without-the-branch-name/">Git Stash Without the Branch Name</a> post by Brandon Pugh.</li> <li><a href="https://devops.com/microsoft-engineers-highlight-git-repository-bloat-flaw/">Microsoft Engineers Highlight Git Repository Bloat Flaw</a> by Adrian Bridgwater on DevOps.com blog (2024).</li> </ul>  <p><strong>Git tools and sites</strong></p> <ul> <li><a href="https://justinpombrio.net/2025/02/11/jj-cheat-sheet.html">JJ (Jujutsu) Cheat Sheet</a> by Justin Pombrio. <ul> <li><a href="https://jj-vcs.github.io/jj/">Jujutsu (<code class="language-plaintext highlighter-rouge">jj</code>)</a>, a Git-compatible version control system, written in Rust, was first mentioned in <a href="https://git.github.io/rev_news/2022/03/31/edition-85/">Git Rev News Edition #85</a>.</li> </ul> </li> <li><a href="https://beej.us/guide/bggit/">Beej’s Guide to Git</a>.</li> <li><a href="https://lmaxence.github.io/gookme/">Gookme</a> is a simple and easy-to-use, yet powerful and language agnostic Git hook manager for <a href="https://monorepo.tools/">monorepos</a>. Successor of Mookme. Written in Go, under MIT license.</li> </ul> <h2 id="releases">Releases</h2> <ul> <li>Git <a href="https://public-inbox.org/git/xmqqzfi8bljk.fsf@gitster.g/">2.49.0-rc0</a></li> <li>Git for Windows <a href="https://github.com/git-for-windows/git/releases/tag/v2.49.0-rc0.windows.1">2.49.0-rc0(1)</a>, <a href="https://github.com/git-for-windows/git/releases/tag/v2.48.1.windows.1">2.48.1(1)</a></li> <li>GitHub Enterprise <a href="https://help.github.com/enterprise-server@3.16/admin/release-notes#3.16.0">3.16.0</a>, <a href="https://help.github.com/enterprise-server@3.15/admin/release-notes#3.15.3">3.15.3</a>, <a href="https://help.github.com/enterprise-server@3.14/admin/release-notes#3.14.8">3.14.8</a>, <a href="https://help.github.com/enterprise-server@3.13/admin/release-notes#3.13.11">3.13.11</a>, <a href="https://help.github.com/enterprise-server@3.12/admin/release-notes#3.12.15">3.12.15</a></li> <li>GitLab <a href="https://about.gitlab.com/releases/2025/02/26/patch-release-gitlab-17-9-1-released/">17.9.1, 17.8.4, 17.7.6</a>, <a href="https://about.gitlab.com/releases/2025/02/20/gitlab-17-9-released/">17.9</a>, <a href="https://about.gitlab.com/releases/2025/02/12/patch-release-gitlab-17-8-2-released/">17.8.2, 17.7.4, 17.6.5</a></li> <li>GitKraken <a href="https://help.gitkraken.com/gitkraken-client/current/">10.7.0</a>, <a href="https://help.gitkraken.com/gitkraken-client/current/">10.6.3</a></li> <li>GitHub Desktop <a href="https://desktop.github.com/release-notes/">3.4.17</a>, <a href="https://desktop.github.com/release-notes/">3.4.16</a></li> <li>Sourcetree <a href="https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.11.html">4.2.11</a></li> <li>tig <a href="https://github.com/jonas/tig/releases/tag/tig-2.5.12">2.5.12</a>, <a href="https://github.com/jonas/tig/releases/tag/tig-2.5.11">2.5.11</a></li> <li>Garden <a href="https://github.com/garden-rs/garden/releases/tag/v2.1.0">2.1.0</a></li> <li>Git Cola <a href="https://github.com/git-cola/git-cola/releases/tag/v4.12.0">4.12.0</a></li> <li>GitButler <a href="https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.8">0.14.8</a>, <a href="https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.14.7">0.14.7</a></li> <li>Tower for Mac <a href="https://www.git-tower.com/release-notes/mac?show_tab=release-notes">12.5, 12.5.1, 12.5.2</a> — <a href="https://www.git-tower.com/blog/tower-mac-125/">Release blog post</a></li> </ul> <h2 id="credits">Credits</h2> <p>This edition of Git Rev News was curated by Christian Couder <<a href="mailto:christian.couder@gmail.com">christian.couder@gmail.com</a>>, Jakub Narębski <<a href="mailto:jnareb@gmail.com">jnareb@gmail.com</a>>, Markus Jansen <<a href="mailto:mja@jansen-preisler.de">mja@jansen-preisler.de</a>> and Kaartic Sivaraam <<a href="mailto:kaartic.sivaraam@gmail.com">kaartic.sivaraam@gmail.com</a>> with help from Chris Torek, Štěpán Němec, Bruno Brito and Brandon Pugh.</p> </div> </article> <div class="footer">  </div> </div> <div id="menuLinkBar"><a href="#navbar">Menu</a></div> </div>  <script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-68655198-1', 'auto'); ga('send', 'pageview'); </script> </body> </html>