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.
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:
- bl/cherry-pick-empty (2024-03-11) 7 commits
where bl are the initials of the author, and cherry-pick-empty
the series title,
- cherry-pick: add
--emptyfor more robust redundant commit handling- cherry-pick: enforce
--keep-redundant-commitsincompatibility- sequencer: do not require
allow_emptyfor redundant commit options- sequencer: treat error reading
HEADas unborn branch- rebase: update
--empty=askto--empty=stop- docs: clean up
--emptyformatting in git-rebase (1) and git-am (1)- docs: address inaccurate
--emptydefault with--exec
“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-emptyoption, which was unnecessary. Its UI has also been tweaked a bit.
Comments?
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.
Various
Light reading
git switch, git restore,
git sparse-checkout, git worktree, and (not new) git bisect.git push?
by Li Zhennan, on the personal blog.git str), a tool to send and receive Git patches
over Nostr, using NIP-34
(mentioned in Git Rev News Edition #109),
and git-ssb
(see the git-ssb-intro guide), a
decentralized Git repo hosting and issue tracking on Secure-ScuttleButt (SSB)
(mentioned in Git Rev News Edition #26
and #40).Easy watching
Git tools and sites
git bisect-find is
a simple command to find where to start your bisection. Written in Rust.
git bisect-find
by Kevin Cox on his blog.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.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.
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.gitlolcommits: 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.jj) is a version control system
first mentioned in Git Rev News Edition #85;
additionally, links to the LWN.net article
and the Jujutsu: A Git-Compatible VCS
talk about this version control system at Git Merge 2022 can be found in
Git Rev News Edition #107.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.