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.
What’s cooking in git.git (Nov 2022, #05; Tue, 22)
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.
Git Bug Report: out of memory using git tag
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.
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 --trailer option to 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?
Recently I’ve been working on implementing a --scope option for git diff
and other Git commands. It tries to limit the scope of the file path to the
sparse specification.
The reason I wanted to implement this feature is that I was researching
how monorepo users collaborate and discovered that git pull might 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 --scope option, 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 switch and
git restore would 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?
If there’s one tip you would like to share with other Git developers, what would it be?
Stay curious about technology.
Various
glab at your fingertips with the GitLab CLI
by Kai Armstrong on GitLab Blog.Light reading
.gitignore
files. Article by Gabor Szabo on DEV.to (also known as The Practical Dev).
There is also some good information in the comments.git rebase
by Sean Larkin on DEV.to.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
.gitignore files for your project.
.gitignore file templates..gitignore tutorial..gitignore files,
which uses GitHub’s gitignore repository for gitignore templates,
was mentioned in Git Rev News Edition #6.xls/xlsx/xlsm/xlsb, csv, txt, dif, and ods formats.
There are also commercial Diffchecker Pro service and Diffchecker Desktop apps.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 ZheNing Hu, Philip Oakley, Junio Hamano and Mirth Hickford.