Git Rev News: Edition 94 (December 31st, 2022)
Welcome to the 94th 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 2022 and December 2022.
Junio Hamano, the Git maintainer, sent one of his usual “What’s cooking in git.git” emails to the mailing list. At the beginning of the email though he thanked everybody for “successfully concluding the ‘bus factor’ exercise”.
It was indeed the first time in a few years that he temporarily handed over the maintainership of the project to someone else, in this case Taylor Blau, as he was having a vacation. It’s called a ‘bus factor’ exercise as it’s supposed to make a transition smoother in case the current maintainer would be “hit by a bus”.
The previous “What’s cooking in git.git” email had been sent a few days before by Taylor, who also thanked everyone, as he saw that Junio was back online again.
Martin Englund sent a bug report to the Git mailing list saying that after creating a signed tag using a ssh-agent key, he ran the following command that should have shown the body part of the tag contents:
git tag -l --format '%(contents:body)' v0.6.1
But instead of displaying anything, the command crashed with:
fatal: Out of memory, malloc failed (tried to allocate 18446744073709551266 bytes)
Peff, alias Jeff King, thanked Martin for the report and said he had found the function where the crash happened and the reason why it happened. He also provided minimal reproduction instructions as well as the commit that introduced the bug, and he put the author of that commit in CC of his email.
Philippe Blain, the author of the commit, thanked Peff for the information and said he would try to find a fix for the bug.
Peff replied to Philippe that after sleeping on the issue, he fully understood what happened. He said there were actually two closely related bugs and he was sending 2 patches to fix them both.
The first patch was a fix for cases where there was no blank line between the subject of a tag and the signature in it, and when the signature also contained no blank line. Such signatures could be generated by ssh.
In such cases the code wasn’t properly detecting the start of the signature and was instead using the end of the commit. When computing the signature length, this would give a negative value, which was then converted to a huge value as the variable for the signature length used an unsigned type. In turn when allocating memory for the signature, this would lead to the crash as it wasn’t possible to allocate the requested amount of memory for it.
The second patch fixed a similar bug that occurred when there was a blank line in the signature but not before it, and this blank line ended with both the CR (Carriage Return) and LF (Line Feed) characters instead of only the latter.
In that case, the start of the signature was also not properly detected, so a negative value was assigned to the variable for the signature length, which led to a crash when allocating memory for the signature.
Both patches are very well explained in long commit messages. This prompted Elijah Newren to reply to Peff joking about the fact that Peff’s patches didn’t set new records for the ratio of commit message lines to changed code, as a previous patch from Elijah contained 96 lines of explanation to describe a one-line fix.
In the same spirit, Peff replied to Elijah providing a script to find the commit with the highest ratio between lines of explanations in the commit message and the lines in the patch. He said that the script would show “a few in the 100’s”.
Ævar Arnfjörð Bjarmason then replied to Peff contesting the method used in Peff’s scripts and suggesting computing “the Levenshtein distance of the pre- and post-image”, and then using that distance to commit message length instead of the previous ratio, which would find other winners.
Elijah ended this subthread of discussion about the biggest comment to code ratio in a commit in the Git repo with:
“Hehe, my offhand joke started a contest over the whimsical question of who’s the most long-winded. I think my work here is done. :-)”
Eric Sunshine, after reviewing Peff’s patches, commented that they were well explained and that he found no suggestion to improve on them.
Philippe agreed with Eric that the patches were very well explained and asked Peff about the case where there would be both no blank line and lines terminated with both CR and LF in the tag. Peff then confirmed that this would be properly handled by his first patch.
Taylor Blau, who was handling the maintainer’s role in the project at that time, as Junio Hamano was having a vacation, also agreed that the patches were very well explained, and agreed to take them. The patches were then merged and part of the Git v2.39.0 feature release.
Developer Spotlight: ZheNing Hu
Who are you and what do you do?
My name is ZheNing Hu, and I am a participant in the GSOC 2021 Git community. Currently I am interning at Alibaba (China).
What would you name your most important contribution to Git?
When I used
git shortlog --author="ZheNing Hu"to look at the patches I contributed, I was ashamed to find that my patches are quite small and simple, because I’m more of a Git learner right now 😄.
If I had to pick one, I’d say it’s adding the
git commit. It is very convenient to add something like “Signed-off-by”, “Reviewed-by” at the end of the commit message.
What are you doing on the Git project these days, and why?
The reason I wanted to implement this feature is that I was researching how monorepo users collaborate and discovered that
git pullmight download Git objects outside of the sparse specification. Meanwhile, Elijah Newren is contributing the technical documentation of git-sparse-checkout [ source ], the article details how other Git commands should properly recognize sparse-checkout, and suggests implementing the
--scopeoption, which I think will solve the problem I encountered above, so I hope to implement it.
This patch was put on hold by me for a while, as no one seemed to review it.
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’d like to have a well-developed concurrency model on the Git server side. See “Question: How to execute git-gc correctly on the git server” for more details.
If you could remove something from Git without worrying about backwards compatibility, what would it be?
git checkout. It can be used to switch branches or restore working tree files, I think these two functions are somewhat coupled. I don’t know if
git restorewould be perfect replacements for it.
What is your favorite Git-related tool/library, outside of Git itself?
scalar. Now I really like to use scalar to download Git repositories to save time.
Do you happen to have any memorable experience w.r.t. contributing to the Git project? If yes, could you share it with us?
Mainly during GSOC, my mentor Christian Couder and many people in the Git community helped me, and I learned how to participate in open source for the first time. It was a great experience to be brave and discuss technology with people from all over the world.
What is your toolbox for interacting with the mailing list and for development of Git?
GitGitGadget. It has a clean commit process, and it runs GitHub action to help me find out if my patch is buggy before committing to the community.
What is your advice for people who want to start Git development? Where and how should they start?
- First become its user
- Understand its principles through the documentation
- Read the source code to understand the general structure of the project
- Understand some sub-modules of the project by solving some problems
- Learn from others with an open mind
If there’s one tip you would like to share with other Git developers, what would it be?
Stay curious about technology.
- Git 2.39.0, 2.38.2, 2.39.0-rc2, 2.39.0-rc1
- Git for Windows 2.39.0(2), 2.39.0(1), 2.39.0-rc2(1), 2.39.0-rc1(1)
- GitHub Enterprise 3.7.2, 3.6.5, 3.5.9, 3.4.12, 3.3.17
- GitLab 15.7 15.6.3, 15.5.6, 15.6.2, 15.6.1, 15.5.5 and 15.4.6
- GitKraken 9.0.0
- Sourcetree 4.2.1
- git-assembler 1.3
- Siddharth Asthana, who worked on Git during his GSoC 2022 for GitLab, is looking for a 6-month Engineering internship, either full-time starting from mid-July 2023 or part time starting now. See his resume for more information.
- Highlights from Git 2.39 by Taylor Blau on GitHub Blog.
glabat your fingertips with the GitLab CLI by Kai Armstrong on GitLab Blog.
- Andrew Morton’s first pull request by Jonathan Corbet on LWN.net (from May 2022).
- Billions of unnecessary files in GitHub
and Git repositories in general, due to missing or lacking
.gitignorefiles. Article by Gabor Szabo on DEV.to (also known as The Practical Dev). There is also some good information in the comments.
- What are your git aliases? by Jose Angel Munoz on DEV.to.
- How to Close a Pull Request - Merge Commit vs Squash vs Rebase on GitHub by Leonardo Montini.
- What is GitOps? on GitLab.
- GitOps viewed as part of the Ops evolution by Viktor Nagy o GitLab Blog (2021).
- A meta talk about Git strategies for deployment (GitOps-like), by Morten Olsen on DEV.to.
- Rebases in Git and why you shouldn’t be afraid of them by Marcin Wosinek for How to dev (also reposted on DEV.to).
- Take advantage of Git rebase by Christian Couder on GitLab Blog.
- Split a commit into 2 commits with
git rebaseby Sean Larkin on DEV.to.
- Minimum Viable Git for Trunk-based Development by Eli Schleifer on trunk.io blog (a Medium-based blog).
- Benefits of Using Pull Requests for Collaboration and Code Review by Fatos Morina on NVIDIA Developer Technical Blog.
- How to revert a merge commit then merge again by Jb Rocher on his blog (also on DEV.to).
- Git worktree by Flavio Poletti (@polettix) on his ETOOBUSY blog.
- Git Notes: Git’s Coolest, Most Unloved Feature by Tyler Cipriani on his blog.
- Learn Git: 3 commands to level up your skill by Dwayne McDaniel on Opensource.com.
- Code version best practices with clean commit formats, following Angular commit convention guidelines, by Chaitanya S. on Halodoc blog.
- Resolving Merge Conflicts with Visual Studio Code by Leonardo Montini (also on This is Learning DEV.to blog).
- 30+ Commonly Asked Git Interview Questions on InterviewBit.
- Extremely Linear Git History,
where first commit in a repo hash a hash that starts with
0000000, the second commit is
0000001, the third is
0000002, and so on is possible with extremely-linear (aka
git linearize) tool. Article and tool by Gustav Westling. ☺
Git tools and sites
- git-credential-oauth is a Git credential helper that securely authenticates to GitHub, GitLab, BitBucket and other forges using OAuth.
- semantic-release (documentation) is a fully automated version management and package publishing Node.js tool.
- Release Please is a Node.js tool that automates CHANGELOG generation, the creation of GitHub releases, and version bumps for your projects; it does so by parsing your Git history and looking for Conventional Commit messages.
- gitignore.io by Toptal
is a service that creates useful
.gitignorefiles for your project.
is GitHub’s collection of
- Atlassian’s Bitbucket has a
- GitLab provides a .gitignore API on all tiers.
a Node.js command-line tool for quickly setting up
.gitignorefiles, which uses GitHub’s gitignore repository for gitignore templates, was mentioned in Git Rev News Edition #6.
- .gitignore Generator extension for Visual Studio Code, which uses the gitignore.io API, was mentioned in Git Rev News Edition #57.
- github/gitignore is GitHub’s collection of
- Diffchecker.com is an online service that
will compare text to find the difference between two text files; there is also
an option for comparing images,
and spreadsheets in
odsformats. There are also commercial Diffchecker Pro service and Diffchecker Desktop apps.
- OpenGitOps is a set of open-source standards, best practices, and community-focused education to help organizations adopt a structured, standardized approach to implementing GitOps.
- Semantic Versioning Specification (SemVer) is a simple set of rules and requirements that dictate how version numbers are assigned and incremented.
This edition of Git Rev News was curated by Christian Couder <email@example.com>, Jakub Narębski <firstname.lastname@example.org>, Markus Jansen <email@example.com> and Kaartic Sivaraam <firstname.lastname@example.org> with help from ZheNing Hu, Philip Oakley, Junio Hamano and Mirth Hickford.