2023-03-31-edition-97.markdown

title	layout	date	author	categories	navbar
Git Rev News Edition 97 (March 31st, 2023)	default	2023-03-31 12:06:51 +0100	chriscool	news	false

Git Rev News: Edition 97 (March 31st, 2023)

Welcome to the 97th 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 February 2023 and March 2023.

Discussions

Support

• Bug report: symbolic-ref --short command echos the wrong text while use Chinese language

  Mengzi Yi (孟子易) sent a bug report to the mailing list saying that when a Chinese name like 测试-加-增加-加-增加 was given to a branch, then calling git symbolic-ref --short HEAD on that branch didn't result in the right output (for example 测试-� instead of maybe 测试-加).

  Peff, alias Jeff King, replied saying that he couldn't reproduce the issue on Linux and wondered if it was related to using MacOS as its HFS+ filesystem might do some Unicode normalization. He said that it might alternatively be related to the shortening code in shorten_unambiguous_ref() treating the names as bytes instead of characters. Another possibility he mentioned was that the shortening code, which used scanf(), was assuming that the resulting string could not be longer than the input, but that this might be wrong when some Unicode normalization and locale were used.

  Eric Sunshine replied to Peff saying he was able to reproduce the bug on MacOS 10.13 (while Mengzi used MacOS 13.2), but that it didn't appear to be related to HFS+ Unicode normalization as on disk the bytes of the branch name he got were the same as what Peff got on Linux.

  Peff replied to Eric asking if he could test a patch that would add debug output and allocate twice as much memory for the shortened name that would store the output from scanf() than for the input of that function. Peff said the debug output on his Linux machine showed that the input was 39 bytes long while the output was 28.

  Eric tested Peff's patch and initially reported 39 and 9 for the input and output respectively. When setting LANG=zh-CN.UTF-8, he got the same input and output lengths as Peff though, which pointed to scanf() being indeed the culprit.

  Junio Hamano, the Git maintainer, replied to Eric's findings saying "Well, that's ... criminal." and wondering if setting LANG to $ANY_VALID_ONE.UTF-8 would work the same way.

  This made Eric realize that the zh-CN language code he used was invalid (it should have been zh_CN, so with an underscore character instead of a dash). Eric anyway found out that using valid LANG codes like en_US, fr_FR, de_DE, ru_RU and zh_CN resulted in the 测试-? truncated output, while using LANG=C yielded the correct 测试-加-增加-加-增加 output.

  Junio, Peff and Eric discussed these results further, wondering what scanf() on MacOS could be doing wrong. Then Peff suggested replacing the call to this function with some manual parsing, and sent a sample in-email patch to do that.

  Eric tested Peff's patch and reported that it looked correct, worked nicely and fixed the issue. He also agreed with the approach of getting rid of scanf() calls in general.

  Peff then sent a regular small patch series based on his previous patch, which fixed a leak and made the changes easier to follow.

  Junio and Eric reviewed the series and then discussed with Peff a bug Junio found in it. Then Peff sent a version 2 of the patch series that fixed the bug and added tests.

  Torsten Bögershausen in the meantime tried to reproduce the original bug and discussed how to do that with Eric. He also commented on the new tests in the version 2 of the patch series as he found that it wasn't clear in which context the bug could appear. Junio suggested some clarifications that were approved by others. The resulting patches were merged and included in the recent Git v2.40.0 release.

Releases

• Git 2.40.0, 2.40.0-rc2, 2.40.0-rc1
• Git for Windows 2.40.0(1), 2.40.0-rc2(1), 2.40.0-rc1(1), 2.40.0-rc0(1)
• libgit2 1.6.3, 1.6.2
• GitHub Enterprise 3.8.1, 3.7.8, 3.6.11, 3.5.15, 3.4.18, 3.8.0, 3.7.7, 3.6.10, 3.5.14, 3.4.17
• GitLab 15.10 15.9.3, 15.9.2, 15.8.4, and 15.7.8
• Gitea 1.19.0
• Gerrit Code Review 3.7.2
• GitKraken 9.2.1, 9.2.0
• GitHub Desktop 3.2.0
• Sourcetree 4.2.2
• Tower for Windows 4.3

Other News

Various

• Highlights from Git 2.40 by Taylor Blau on GitHub Blog.
• public-inbox.org/git to be downgraded to a cheaper VPS.
  • There is https://lore.kernel.org/git/ if there are problems with the public-inbox.org instance.
• Unleash your potential with GitHub Octernships: a path to a thriving tech career by Arkodyuti Saha on GitHub Blog.
• Future-proofing Git repository maintenance by Patrick Steinhardt on GitLab blog.
• Notes from a video conference on Thursday March 30 named libification eng discussion organized by Emily Shaffer are available.

Light reading

• How to Improve Performance in Git: The Complete Guide by Bruno Brito on Tower’s blog.
• Integrating 1Password SSH with Git (and Tower!) by Bruno Brito on Tower’s blog.
• Slice, Dice, and Squash Your Git Commit History by Anthony Fung on Diary of a Web Developer Substack and on DEV.to as 3rd part of The Secret of Tidy Git Repositories Series.
• Git fundamentals, a complete guide by Leandro Proença on DEV.to.
  See also:
  • Git from the Bottom Up by John Wiegley, mentioned in Git Rev News Edition #2,
  • Git for Computer Scientists by Tommi Virtanen,
  • and maybe also Think Like (a) Git: a guide for the perplexed by Sam Livingston-Gray.
• Options to close pull requests on GitHub and Merge, squash & rebase on GitHub - pros & cons by Kacper Rychel on DEV.to.
• How to Reset a File or Commit in Git by Ihechikara Vincent Abba on freeCodeCamp.
• How atomic Git commits dramatically increased my productivity - and will increase yours too by Samuel Faure on DEV.to and on Such Dev Blog.
• Working with Git in JetBrains' Rider IDE by Andrew Lock on his .NET Escapades blog.
• GitHub Desktop 3.2 adds pull request preview – but is a GUI needed for Git? by Tim Anderson on Dev Class.
• Best 8 Data Version Control Tools for Machine Learning 2023 by Zoumana Keita on DagsHub Blog.
  • See also links about data versioning in previous Git Rev News.
• A better Git workflow? proposal by uje on the Julia Language Discourse forum.
• Code Commit Guidelines using Conventional Commits by Pragnesh Ghoda on ProAndroidDev, a Medium blog.
  • The Conventional Commits specification was first mentioned in Git Rev News Edition #52.

• Empowering weak primitives: file truncation to code execution with Git by Thomas Chauchefoin on Sonar(Source) Blog (note that it is not about a vulnerability in Git).
  References the Securing Developer Tools: Git Integrations blog post.
• What the ML is up with DevSecOps and AI? by Taylor McCaslin on GitLab Blog.

Git tools and sites

• There are a few tools that use GPT-3 / ChatGPT Large Language Model (LLM) to help write commit messages. Please read the proposed commit message before accepting it, especially for more complex changes. Those tools, as far as we understand it, do not take information from an issue tracker, or from code review comments attached to a pull request (or contained in a specialized tool such as Gerrit) -- so they cannot add this information to the proposed commit message, they can only halucinate it.
  All tools listed here require an API key from OpenAI.

  • OpenCommit is a GPT CLI to auto-generate impressive commits in 1 second; it uses Conventional Commits, and can use GitMoji. Written as Node.js CLI app.
    • See also OpenCommit: GPT generates impressive commits in 1 second (open-source) by Dima Sukharev on DEV.to.
  • AI Commits is a CLI app (aicommits) that writes your Git commit messages for you with AI, that can also be used as prepare-commit-msg hook. Written as Node.js v14+ CLI app.
    • See also AI generated Git commit messages by Brian Douglas on DEV.to.
  • ai-commit is a command line tool that uses OpenAI's language generation capabilities to generate conventional commit messages for your Git repositories. Written in Go.
  • gptcommit is a Git prepare-commit-msg hook for authoring commit messages with OpenAI's GPT-3 language model. Written in Rust.
    • Mentioned in Git Rev News Edition #95; see also an article about this tool there.

• Planar is a Chrome extension that adds features used internally by big tech to speed up and simplify GitHub code review.

  • See also Planar - Add 10x features to GitHub code review by Eshan Agarwal on Y Combinator (Launch YC).

• Git for Computer Scientists by Tommi Virtanen is a quick introduction to Git internals for people who are not scared by words like directed acyclic graph.

• Think Like (a) Git: a guide for the perplexed by Sam Livingston-Gray, intended for "advanced beginners" with Git to help them achieve some level of Git enlightenment.

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 Bruno Brito.