2022-10-31-edition-92.markdown

title	layout	date	author	categories	navbar
Git Rev News Edition 92 (October 26th, 2022)	default	2022-10-26 12:06:51 +0100	chriscool	news	false

Git Rev News: Edition 92 (October 26th, 2022)

Welcome to the 92nd 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 October 2022.

Discussions

General

• Git participated in GSoC (Google Summer of Code) 2022

  The following contributors have successfully passed their final evaluation and published a final report:

  • Shaoxuan Yuan worked on the More Sparse Index Integrations project project. He was co-mentored by Derrick Stolee and Victoria Dye.

  • Abhradeep Chakraborty worked on the Reachability bitmap improvements project. He was co-mentored by Kaartic Sivaraam and Taylor Blau.

  Also Siddharth Asthana successfully participated in GSoC 2022 for GitLab (instead of Git) and contributed to Git as part of his work on the Add Support for Mailmap project. He was co-mentored by John Cai and Christian Couder.

  Congratulations to these contributors and their mentors!

Reviews

• [PATCH] fuzz: add basic fuzz testing for git command

  Arthur Chan sent a patch to add basic fuzz testing to Git. The patch added a set of helper functions in some fuzz-cmd-base.{h,c} files and a demonstration entry point (called fuzzing target) for LibFuzzer or similar tools to inject fuzzed data into git status in a fuzz-cmd-status.c file.

  Ævar Arnfjörð Bjarmason replied to Arthur. He suggested coding style improvements to better match our style as well as taking a look at the infrastructure code we already have for fuzzing. He also wondered if existing code - that is, APIs for file generation and the shell-based infrastructure in the t/ directory - could not be used for fuzzing, too.

  Arthur replied that he couldn't find existing infrastructure code for fuzzing and that he was confused about avoiding the system(3) calls as they were needed to reset the state of the repo after each round of fuzzing, and the LLVM oss-fuzz library required such resetting logic to be included in the C code.

  Junio Hamano, the Git maintainer, also replied to Arthur saying that, before adding new fuzzing infrastructure, existing one should be moved into a new fuzz/ directory. Junio also suggested some coding style improvements and commented on possible performance and correctness issues.

  Arthur replied to Junio that he implemented the suggested changes in a version 2 of the patch that he was preparing, and then sent this version 2 to the mailing list.

  This version of this patch indeed moved some existing fuzz-commit-graph.c, fuzz-pack-headers.c and fuzz-pack-idx.c files into a new oss-fuzz directory. The patch still added the new fuzzing infrastructure that was in the previous version, though a lot of the issues that had been pointed out were fixed.

  Junio replied that it was better to have the "cleaning up of existing stuff" and "addition of new stuff" split into two separate patches instead of having everything in the same one.

  Arthur agreed to split the move of the existing fuzzing infrastructure into a separate preparatory patch called "fuzz: reorganise the path for existing oss-fuzz fuzzers" that he later sent to the mailing list.

  Junio reviewed the preparatory patch and found that some changes to the .gitignore file were likely missing. He also asked how the fuzzing should be launched.

  Arthur replied agreed that changing the .gitignore file was needed and said that he got privately in touch with people from oss-fuzz targeting Git who had implemented the existing fuzzing. He also said that a Dockerfile and build script prepared for Git would launch the fuzzing.

  Arthur then sent a version 2 of the preparatory patch with a few small fixes and the .gitignore changes that Junio suggested. Soon after he sent a version 3 with very minor changes compared to version 2.

  Ævar replied to this new version suggesting some commit message improvements to better explain the patch purpose as well as creating oss-fuzz/.gitignore instead of changing the .gitignore file at the root of the repository.

  Arthur sent a version 4 with the suggested changes.

  Junio commented a bit on how to make sure people get CC'ed in the emails sent by GitGitGadget but was happy with the patch itself, which has since been merged into the master branch.

  We are looking forward to even more fuzzing infrastructure improvements in the near future.

Releases

• Git 2.38.1 and others, 2.38.0
• Git for Windows 2.38.1(1), 2.38.0(1)
• GitHub Enterprise 3.7.0, 3.6.3, 3.5.7, 3.4.10, 3.3.15, 3.2.20
• GitLab 15.5.1 15.5, 15.4.3, 15.4.2, 15.4.1, 15.3.4, and 15.2.5
• Bitbucket Server 8.5
• Gerrit Code Review 3.4.6, 3.5.3, 3.6.2
• GitHub Desktop 3.1.2, 3.1.1, 3.1.0
• Tower for Windows 4.0 (blog post)

Other News

Events

• The recorded talks of Git Merge 2022 are now live.
• The summary of Git Merge 2022 can be found in the Git Merge 2022 – that’s a wrap! blog post by Lee Reilly on the GitHub Blog.

Various

• Git security vulnerabilities announced (CVE-2022-39253, and CVE-2022-39260) that affect Git's --local clone optimization (important when cloning with --recurse-submodules from untrusted repositories) and git shell's interactive command mode. Fixed in Git 2.38.1.
• Highlights from Git 2.38 by Taylor Blau on the GitHub Blog.
  • See also Git 2.38 Adds Microsoft's "Scalar" Repository Management Tool by Michael Larabel on Phoronix.
• Cybernews research team discovered millions of .git folders exposed to public.
• A Code Review Handbook published by Sledgeworx Software.

Light reading

• Setting Up GPG on Windows (The Easy Way) by Bruno Brito on Tower’s blog.
• Our Favorite Tower Features by Florian Albrecht on Kaleidoscope's blog.
• The Story of Scalar by Derrick Stolee and Victoria Dye on the GitHub Blog.
• Literally the smallest changeset possible created: Fix: remove a ZERO WIDTH NO-BREAK SPACE in front of an inline literal.
• VS Code "Timeline" feature — Your local version control system by Amit Merchant.
• Turn around your Git mistakes in 17 ways by Smitter hane on DEV.to.
• GitHub's Missing Merge Option by Tyler Cipriani, explaining the conflict between team “git log should be clean” vs. team “git log should have an accurate history” and the consequences for GitHub users.
• Take advantage of Git rebase by Christian Couder on the GitLab blog.
• Speed up your monorepo workflow in Git by John Cai on the GitLab blog.
  • See also Scaling Git’s garbage collection, mentioned in Git Rev News #91 and Scaling monorepo maintenance, mentioned in Git Rev News #75.

Git tools and sites

• focus is a tool to manage Git sparse checkouts derived from the Bazel build graph.
• Goblet is a Git proxy server that caches repositories for read access, which is intended to be used as a library. Created at Google as 20% project (with glue code for googlesource.com) as google/goblet, and also used in a modified form at Canva as canva-public/goblet.
  • A different Goblet was some time ago a web frontend for Git repositories in Python, using libgit2 and Flask; the seveas/goblet repository has been archived by the owner.
• nb is a command line and local web note-taking, bookmarking, archiving, and knowledge base application with Git-backed versioning and syncing.
• The Git Reference site is meant to be a quick reference for learning and remembering the most important and commonly used Git commands, but it can also be used as a tutorial. Every page will also link to more in-depth Git documentation.
• email + git = <3: Learn to use email with Git! is a guide to contributing to email-driven projects like the Linux kernel, PostgreSQL, or Git. Covers various operating systems and distributions.

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 Johannes Schindelin and Bruno Brito.