Skip to content

Latest commit

 

History

History
405 lines (334 loc) · 22.8 KB

2022-12-31-edition-94.markdown

File metadata and controls

405 lines (334 loc) · 22.8 KB
title layout date author categories navbar
Git Rev News Edition 94 (December 31st, 2022)
default
2022-12-31 12:06:51 +0100
chriscool
news
false

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.

Discussions

General

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

Support

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

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 --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?

    1. First become its user
    2. Understand its principles through the documentation
    3. Read the source code to understand the general structure of the project
    4. Understand some sub-modules of the project by solving some problems
    5. 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.

Releases

Other News

Various

Light reading

  • 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 Rev News Edition #24 mentions in passing the git-sham tool, which can be used to produce subsequent commits with SHA-1 identifiers beginning with subsequent numbers - but the tool doesn't seem to exist anymore at its original URL.

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 .gitignore files for your project.
  • 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, PDFs, and spreadsheets in xls/xlsx/xlsm/xlsb, csv, txt, dif, and ods formats. 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.

Credits

This edition of Git Rev News was curated by Christian Couder <[email protected]>, Jakub Narębski <[email protected]>, Markus Jansen <[email protected]> and Kaartic Sivaraam <[email protected]> with help from ZheNing Hu, Philip Oakley, Junio Hamano and Mirth Hickford.