Git Rev News: Edition 110 (April 30th, 2024)

Welcome to the 110th 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 March and April 2024.

Discussions

General

  • What’s cooking in git.git (Mar 2024, #05; Tue, 19)

    In March, Junio Hamano, the Git maintainer, sent one of the usual “What’s cooking in git.git” emails that describe the current state of the patch series that might be merged into the development branches (mostly “master”, “next”, and “seen”).

    The patch series are listed in these emails along with some related information in a custom format, including the following elements:

    • a title line, for example:
    • bl/cherry-pick-empty (2024-03-11) 7 commits

    where bl are the initials of the author, and cherry-pick-empty the series title,

    • a patch list, for example:
    • cherry-pick: add --empty for more robust redundant commit handling
    • cherry-pick: enforce --keep-redundant-commits incompatibility
    • sequencer: do not require allow_empty for redundant commit options
    • sequencer: treat error reading HEAD as unborn branch
    • rebase: update --empty=ask to --empty=stop
    • docs: clean up --empty formatting in git-rebase (1) and git-am (1)
    • docs: address inaccurate --empty default with --exec
    • a description, for example:

    “cherry-pick” told to keep redundant commits needs to be allowed to create empty commits to do its job, but it required the user to give the --allow-empty option, which was unnecessary. Its UI has also been tweaked a bit.

    • a status, for example:

    Comments?

    • a source, for example:

    source: 20240119060721.3734775-2-brianmlyles@gmail.com

    Some of the above elements, like the description, are also automatically used to create the release notes that Junio prepares and sends when he creates a new release.

    Brian Lyles replied to Junio that the description of the patch series used as an example above, which Brian had sent, was “a little out-of-date”. He suggested a different wording for it, and said that he was going to send a version 4 of his patch series.

    Junio said that the wording suggestion for the description was very much appreciated, and wondered if the project could adopt a better workflow where contributors could write a short description at the top of the cover letter of their patch series and if that description could then be picked up automatically by some tools to appear in Junio’s “What’s cooking in git.git” emails.

    Brian Lyles agreed that improving the process could be a good idea. He mentioned a strategy used by other projects, namely adding an entry in a “CHANGELOG.NEXT.md” file for each important commit. At release time, all the entries in that file would be moved into a standard “CHANGELOG.md” file. He then showed how the entry in the “CHANGELOG.NEXT.md” file would look like for his series as an example.

    Junio replied by summarizing the current process related to these descriptions and pointing to the “Documentation/howto/maintain-git.txt” file, which describes his workflow and says that maintaining these topic descriptions is his responsibility as the project maintainer. He then mentioned some downsides of giving that responsibility to the patch series authors.

    One downside is that the description might be harder to read because the authors “inevitably are biased by the importance of their own work ;-)”. Another one is that the description might not be as consistent as when they are all written by the same person. Coming up with some description is also “a good opportunity” for the maintainer to find what is still unclear after reading the patches and the cover letter. Junio agreed that “the distribution of burden is certainly attractive” though.

    Brian replied that he thought the author should still write something and that at least he was willing to do it. He also suggested having guidelines, like for commit messages, to help authors and reviewers standardize the style of these descriptions.

    In the meantime, in a separate email, Junio also pointed out that a “CHANGELOG.NEXT.md” file would make merges more difficult compared to having the description in the cover letter.

    To that Brian agreed, and proposed writing a patch to the “Documentation/SubmittingPatches” file to document that the description can be written in the cover letter.

    Junio replied by proposing a patch to that file himself. Brian commented that the description might need “some specific heading, phrase, or other structured text” to mark it appropriately, making it easy to notice and extract.

    Dragan Simic joined the discussion saying that writing the description should not be a strict requirement and then agreed with Junio’s patch. Max Gautier also chimed in, agreeing with Brian and Dragan about using a format to mark the description. Dragan replied that adding an example of such a formatted description in the patch Junio suggested would be good.

    Junio replied to Brian that he preferred starting “with a lightweight process that does not burden participants with too much red tape”, so something like “When the first paragraph of the message looks like an entry in the Release Notes, it is used as such”, as he thought that the Release Notes style was “distinct enough” as to “not require any further marking”.

    As Junio’s patch was then merged, it’s now officially possible to write a short description in patches or cover letters. This description might then be used as-is in the “What’s cooking in git.git” emails and in the release notes.

Other News

Various

Light reading

Easy watching

  • re:bass by Dylan Beattie [4:34]. If Git was music, what would it sound like? An original composition inspired by the Git version control system.

Git tools and sites

  • git bisect-find is a simple command to find where to start your bisection. Written in Rust.
  • git-cz is a command-line tool to help you make semantic Git commits. Written in JavaScript for Node.js. Can be installed standalone, or with Commitizen (which was mentioned in Git Rev News Edition #72). Has non-interactive mode; is configurable (for example turning off emoji).
  • ydiff is a term based tool to view colored, incremental diff in a version controlled workspace (supports Git, Mercurial, Perforce and Subversion so far) or from stdin, with side by side (similar to diff -y) and auto pager support. Written in Python. (Its cdiff fork appears to be unmaintained.)
  • gws is a text user interface colorful helper to manage workspaces composed of Git repositories. Written in Bash.
  • Giftless (GitHub repo) is a Python implementation of a Git LFS Server. It is designed with flexibility in mind, to allow pluggable storage backends, transfer methods and authentication methods.
  • gil (git links tool) is a tool to manage complex recursive repository dependencies with cross references and cycles. This tool provides a solution to the git recursive submodules dependency problem. Written in Python.
  • git subrepo “clones” an external Git repo into a subdirectory of your repo. It is an alternative to git submodule and git subtree. The subrepo history is squashed into a single commit that contains the reference information. Recommended as replacement for the (no longer maintained) Git STree project.
  • tomono: Multi- to Monorepo Migration, is a script that merges multiple independent tiny repositories into a single “monorepo”. Every original repo is moved into its own subdirectory, branches with the same name are all merged.
    • Can be considered the reverse of splitsh/lite tool, whose goal is to make splitting a monolithic repository to read-only standalone repositories easy and fast (mentioned in Git Rev News: Edition #16).
  • gitdm (the “git data miner”) is the tool that Greg KH and Jonathan Corbet have used to create statistics on where kernel patches come from. Written in Python. Original at git://git.lwn.net/gitdm.git
  • lolcommits: Git-based selfies for software developers. lolcommits takes a snapshot with your webcam every time you execute git commit, and archives a lolcat style image with it (image with embedded caption). Written in Ruby, requires a webcam and ImageMagick installed. See also Lolcommits from around the world! page on the project Wiki.
  • Steve’s Jujutsu Tutorial.
  • Awesome Git is a curated list of amazingly awesome Git tools, resources and shiny things.
  • Awesome Git Hooks is a curated list of easy-to-use Git hooks for automating tasks during Git workflows.

Releases

Credits

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 Junio Hamano, Štěpán Němec, Kristoffer Haugsbakk, Dragan Simic and Adam Johnson.