Welcome to the 84th 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 month of January 2022.

• Join us for Review Club!

  Josh Steadmon announced that the Review Club meeting he has been organizing at Google for a while is now open to everyone. It happens every other Wednesday at 14:00 Pacific time (UTC-8) via Google Meet.

  The first opened meeting happened on Wednesday February 2nd and discussed Elijah's "In-core git merge-tree" patch series.

  Please contact Josh Steadmon at steadmon@google.com if you are interested and want to join.

• [PATCH] fetch --prune: exit with error if pruning fails

  Thomas Gummerer sent a patch so that git fetch, when it's used with the --prune flag or its -p short form, will not exit with exit status 0 anymore if pruning a ref fails.

  Pruning a ref means removing a remote tracking ref, usually a branch, if the ref disappeared on the remote. For example, if a remote called origin has a branch called feature1, then fetching from origin will cause Git to create a remote tracking branch called origin/feature1 on the local machine. After the feature1 branch is removed on origin, subsequent fetches from origin will yield the deletion of the local origin/feature1 branch only if pruning is requested.

  Thomas noted in his patch that an error message was already printed on stderr when pruning a ref failed, but it felt like a bug that git fetch was still exiting with the 0 exit status in this case, as this could be interpreted as if no error happened.

  Thomas had looked up the commit that introduced pruning, but he couldn't find if the exit status behavior was "an oversight or intentional", but it felt like an oversight to him.

  Junio Hamano, the Git maintainer, agreed with Thomas about using a non-zero exit status when ref pruning failed, but he was unsure about which actual exit status would be emitted by the code in Thomas' patch.

  Junio also found an issue with the current code as in some cases it appeared that -1 could be passed to exit(). This would result in a 255 exit status, as exit statuses have only 8 bits and are unsigned. He left a #leftoverbits mention related to this in his email, which helps find usually small issues that should be fixed later.

  Junio also thought that is probably wasn't a good idea to error out as soon as an error happens when pruning. It was probably best to continue to fetch and prune as much as possible, "given that we have already paid for the cost of discovering the refs from the other side".

  Thomas' patch added a new regression test that was then discussed a bit by Junio, who left another #leftoverbits mention related to the fact that many tests in the test script, where Thomas added the new test, were using an old style and might want a cleanup.

  Dscho, alias Johannes Schindelin, replied to Junio that it might actually be confusing and unexpected for users if the fetch would continue when pruning failed. He suggested adding a --prune-best-effort option for cases where we might want the fetch to continue as much as possible when pruning fails.

  Thomas replied to Dscho that he was unsure what the behavior should be when writing the patch, but that exiting early "felt like the right thing to do for the user". He said that he would be OK with introducing --prune-best-effort. He wasn't sure people would actually use it much though, as "it should be very rare that --prune fails".

  Junio replied to Thomas and Dscho that "when we fetch to update multiple refs, we do not stop at the first ref-update failure, but try to do as much as possible and then report an error", and that --prune should behave similarly.

  Thomas also replied separately about Junio's initial comment related to the actual exit status that would be emitted after Thomas' patch. He wondered if the exit status should always be 1 when git fetch fails at pruning.

  Thomas and Dscho then discussed the new test, following Junio's comments, and agreed on adding a comment in the code to explain what the test was doing.

  Thomas then sent a version 2 of his patch with the changes that had been discussed.

  Junio reviewed this new version and decided to merge it down, so this small improvement will be in the next Git version.

(Eric has already been interviewed in Git Rev News #7, September 2015.)

• Since your previous interview, have there been changes in who you are and what you do?

  About a year after the previous interview, taking on the role of caregiver for a family member consumed the bulk of my time to the point that I was unable to keep up with the Git project or contribute in any meaningful way, and was effectively absent from the project for at least a year and a half. Since returning to the project, my contributions have been far more scarce due to time constraints of "real life" and a new job which I started a few years ago.

• You were a long-time RCS, CVS, and Subversion user. Do you miss any features of those version controls systems in Git?

  I can say without hesitation that I do not miss any features of those older version control systems. In fact, I can report (perhaps happily) that I have mostly forgotten how to use them. This is true of Subversion, in particular, in which I have had to consult the documentation to tackle even the simplest tasks the couple times I had to use it in the last few years, despite having been a longtime and experienced user.

• How are your contributions to Git these days? Code contributions? Code reviews? Others?

  In the past, I was generally able to keep up with the mailing list and read most or all patches submitted to the project and often provide detailed reviews, but my Git time is fairly limited these days, so I have to be much more selective about which topics I follow or participate in.

  Since I contributed quite a bit to the git worktree command (and am perhaps an "area expert", especially since Nguyễn Thái Ngọc Duy departed from the project), I pay particular attention to bug reports about that command or topics touching it in some significant fashion. In the case of a bug report, I either provide a fix for the problem myself or help guide some other contributor. In the case of topics which touch git worktree, I try to set aside time to review the topic's patches carefully and follow along as the topic progresses.

  That aside, I also provide reviews for other topics when they fit into my limited Git time, and answer the periodic question on the mailing list, or interact in a discussion if I have something meaningful to offer on the subject.

• Are 'ability to stage changes' and 'interactive rebase' still your favorite Git features? Or do you have new favorites?

  Yes they are, and no I do not have new favorites.

  In fact, a few years back, I started using the src version control system for managing standalone files (which, although built atop RCS, features a "modern" command line interface quite like Git's and in no way like RCS's interface). Although I find src handy for versioning standalone files, I always feel as if my hands are tied when using it since it lacks the very useful features of staging changes and rebasing interactively.

  As a consequence, aside from contributing bug fixes and enhancements to the project, I also spent some time significantly improving the fast-import and fast-export round trip fidelity of src. This allows me to temporarily import a src history into Git, which gives me access to Git's staging and interactive rebasing, and finally convert the history back to src. Yes, it's a terrible kludge, and a painful one, but at least gives me a way to take advantage of those Git features when absolutely required. I don't use src often enough presently to justify the development effort, but adding staging and interactive rebasing to the tool directly would be on my wish list for that project.

• How does your mailing list workflow look like?

  I understand that some developers have special tooling set up to improve the mailing list-centric workflow on the Git project, but I still use a plain email client with no special provisions, and I likely will continue with this set-up as long as it works well enough for my simple needs.

  I do find the Git mailing list archive at https://lore.kernel.org/git quite useful and often go spelunking through it when researching some topic or bug report, as well as to fetch sets of patches which I may have already deleted from my local email client. Much more recently, I have also started taking advantage of its NNTP feed (nntp.lore.kernel.org).

• Could you elaborate a bit about the email client you use?

  I use Gmail in the web browser almost exclusively. Lately, I have been using Thunderbird to access the lore.kernel.org NNTP feed. Infrequently, I use mutt when I need to send a patch inline within a reply when I don't want the Gmail web interface to modify whitespace or the formatting in general. (I also have Emacs set up for email, thus could use it for the same purpose as mutt, but never actually do so.)

  [ Editor's note: If you're going to use Gmail in the web browser, ensure "Plain text mode" is checked. Also, see Gmail specific format-patch hints ]

• What is your advice for people who want to start Git development? Where and how should they start?

  Getting involved in the Git project can be intimidating (I know, even after all these years, I still feel intimidated each time I submit patches), but people on the project are generally quite friendly, and the goal of reviewers is to help you refine your submission so that it can eventually be accepted into the project. After all, that's why reviewers take the time to read submissions so thoroughly and offer (sometimes in-depth and exhaustive) comments to improve the submission. One thing to note: people who review a lot of patches tend (out of necessity) to be economical with their words, pointing out just the parts of the patch which need improvement and often forgetting to praise the parts which are done well. As such, reviews can sometimes feel cold and off putting, but that is not the intention. Reviewers are genuinely trying to help; they would not put in such effort otherwise.

  A good way to learn how the project works is to subscribe to the mailing list and read submissions from active contributors and reviews from regular reviewers. You can learn by example via passive observation. From a patch or patch series, you can learn not only how a patch series should be constructed, but also how an effective commit message is written. By reading reviews, you can learn what reviewers are looking for and how they interact.

  To become actively involved in the project, submit a patch, even a small one fixing a bug you found or making a minor improvement to documentation. If you have an idea for a functionality improvement or a new feature, send it to the mailing list. Or, if you just want to contribute without having anything particular in mind, monitor the mailing list for bug reports (as I did when I joined the project) and try to devise a fix and submit it to the mailing list in the form of a patch.

  Another way to contribute to the project is by reviewing submissions. Reviews do not need to be extensive or elaborate. A review which points out a minor logic flaw in a patch or highlights a typographical error in a comment or commit message is useful.

• If there's one tip you would like to share with other Git developers, what would it be?

  When reviewing a patch, make it clear which of your comments you expect the submitter to act upon and which suggestions can be left to the discretion of the submitter. This is especially important for new contributors who may not be able to distinguish between mandatory changes to the patch and "it might be nice to have" changes. Also let the submitter know that it is okay to push back on a review comment if necessary since newcomers may not realize that doing so is an option.

  For a submitter, try to respond to each review comment -- even if the response is a simple "OK" or "I agree with all your comments" or "I disagree with this comment because..." -- so that reviewers do not feel that their effort has been wasted.

  (Oops, that's two tips, not one. Sorry.)

• What would you name your most important contribution to Git?

  It is difficult to judge the importance of various contributions. I may instead be able to highlight a few areas in which I have been involved.

  Although I do not do many reviews these days, I used to be an active reviewer, and hope that my review comments and suggestions helped improve various submissions in at least some way.

  From an end-user perspective, perhaps the my most visible contribution to Git has been all the work I did to improve and enhance the git worktree command and multiple-worktree support in general (though much of the praise for the mechanics of multiple-worktree support belongs to Nguyễn Thái Ngọc Duy who designed and originated the implementation).

  From a Git developer perspective, perhaps my most valuable(?) contribution is the so-called chainlint which identifies a specific type of problem in Git test scripts which could, if undetected, allow a test to miss a failure and erroneously report success.

• What are you doing on the Git project these days, and why?

  As mentioned, my Git time is limited, so my involvement is scaled back. I do try to answer a question here or there or contribute to a discussion if possible, and I review the periodic submission.

  Aside from contributing a few bug-fix patches and introducing the git worktree repair command relatively recently, my recent focus has been on a new and much enhanced version of the chainlint tool mentioned above. Although the implementation has been complete for well over a half year (at the time of writing), I am still trying to find time to polish the patch series itself for submission. In the meantime, I did manage to submit a couple other somewhat lengthy patch series in preparation for the new chainlint.

• Git 2.35.1
• Git for Windows 2.35.1(2), 2.35.1(1)
• libgit2 1.4.1, 1.4.0
• GitHub Enterprise 3.3.4, 3.2.9, 3.1.17, 3.0.25, 3.4.0, 3.3.3, 3.2.8, 3.1.16, 3.0.24
• GitLab 14.8 14.7.3, 14.7.2, 14.7.1, 14.6.4, and 14.5.4
• GitKraken 8.3.0
• GitHub Desktop 2.9.9, 2.9.8, 2.9.7
• Tower for Mac 8.0 (What's New in Tower 8 video)

Various

• How some Git fetch performance improvements were made, part 1 and part 2, by the GitLab Scalability team.
• Include diagrams in your Markdown files with Mermaid, automatically rendered on GitHub and possibly also in other CommonMark implementations.
• More ways to keep your pull request branch up-to-date on GitHub.

Light reading

• Cross-fork object sharing in git (is not a bug) by Konstantin Ryabitsev.
• Getting Started with Git Bash by Bruno Brito on Git Tower blog.
• Inside the Hidden Git Folder - Computerphile by Dr Max Wilson on Computerphile channel on YouTube. Beware a blink and you miss it error about the purpose of the .git/logs/ folder. A link to the previous video on the topic of Git by Dr Max Wilson can be found in Git Rev News Edition #83 (the previous edition).
• Protect secrets in Git with the clean/smudge filter by Tomer Figenblat on Red Hat Developer blog.
• Git: Switching Unstaged Changes to a New Branch two ways, by Chris Coyier on CSS-Tricks; read also featured comments.

Git tools and sites

• Monorepo.tools -- Everything you need to know about monorepos, and the tools to build them.
  • Announcing monorepo.tools by Juri Strumpflohner for Nrwl.
  • You can find the most recent list of pros and cons of monorepos in Git Rev News Edition #81.

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 Eric Sunshine, Philip Oakley, Bruno Brito and Josh Steadmon.