Git Rev News: Edition 109 (March 31st, 2024)
Welcome to the 109th 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 and March 2024.
Discussions
Reviews
-
[PATCH] rebase: make warning less passive aggressive
Harmen Stoppels sent a patch to the mailing list that changed an error message from “No rebase in progress?” to “No rebase in progress”. The rationale is that this error appears when one runs
git rebase --continue
while there is no rebase going on, so there is no reason for the question mark.Junio Hamano, the Git maintainer, replied to Harmen suggesting using the imperative mood in the commit message, and saying that the change in itself is good but that the patch shouldn’t have touched the
po/*.po
files in the project that are used for localization. Junio also said that we could later add tests for this as it appeared there was none.Michal Suchánek replied to Junio saying that it might have been OK to touch the
po/*.po
files if the patch had updated the translations in those files but it hadn’t.Junio replied to Michal saying that knowing the target language was needed before removing question marks in those files as it might not be enough to change a question into a statement. Even if the author of the patch knew enough, reviewers of the patch might not, but the biggest problem was bypassing the languages teams.
Michal replied to Junio asking what was the problem “with not involving several language teams to remove a question mark”.
Jean-Noël Avila, who is a translator, replied that it didn’t bother him much to edit a sentence to remove a question mark and possibly adjust it, compared to “translating again and again similar sentences”.
This led to some confusion as Junio thought that Jean-Noël said that the “everything in one patch” approach would help translators by not having them translate “again and again”. But Jean-Noël clarified that he didn’t consider changing a question to an assertion is translating “again and again”. He agreed that it was perfectly fine for translators to have to do those kinds of changes. With “again and again” he was referring to strings like “could not stat ‘%s’” and then “could not stat file ‘%s’”.
In the meantime Patrick Steinhardt replied to Harmen’s initial message. He suggested converting the error message to start with a lowercase letter as our guidelines for error messages recommend.
Harmen then sent a version 2 of his patch which didn’t change any
po/*.po
file and had the error message start with a lowercase letter. Patrick reviewed that patch and found it good.Kristoffer Haugsbakk chimed into the discussion saying he had interpreted the original error message as saying “I’m not quite sure but it looks like you are not in the middle of a rebase?”
Junio replied to Kristoffer saying that there are indeed examples of “less assertive” messages in the same rebase command, like “It looks like ‘git am’ is in progress. Cannot rebase.” But we should be more assertive as it could help us get valuable bug reports saying for example “The command said I was not rebasing, but I was! Here is what I did…” Such bug reports could help us improve how we determine the state we are in.
The version 2 of Harmen’s patch was later merged to the ‘master’ branch.
Developer Spotlight: Linus Arver
-
Who are you and what do you do?
I’m one of those so-called “self-taught” developers. My educational background is in English and tax law (I know, boring right?). Over a decade ago I thought I would be a corporate attorney, but in law school I discovered programming and fell completely in love with the craft, and never looked back! In hindsight it was the second-best decision I’ve made in life (the first being getting married to my lovely wife four years ago).
I said that I fell into programming during law school. But actually my original journey started in 7th grade when I tried to pick up C++. I remember learning control flow, structs and pointers in the first few chapters of the book I was using, but when it came to the chapter on OOP and classes, I could not understand why OOP was necessary. The book I was using just explained why OOP was great, and not why it would ever be bad.
Of course, years later I realized that OOP is one of several paradigms, so perhaps my instinct to question OOP as a panacea was onto something. In high school and university I remember tinkering with HTML and websites before smartphones became popular. What a simpler time it was, back then!
Fast forward to law school, where I had the idea of writing class notes using plaintext. Soon after I had the idea of converting these plaintext notes to prettified outlines, so I needed a way to convert them to HTML. For better or worse, all this happened before I discovered Emacs and Org mode (or even Markdown).
Anyway, I first wrote a plaintext-to-HTML converter in Ruby. Then I rewrote it in C just for fun. Then again in Haskell (using a minimal subset of Org mode syntax). As you can see, I sort of got carried away, haha.
I would go on to write dozens of pet projects (rudimentary chess engine, game modding tools, etc) where I got to write tons of code. I’ve had the “ugh, did I really write this?” moment too many times to count. I like to believe that I did the tech industry a favor by not entering it until I was well versed in fundamental programming and architectural concepts. 😉
Since those law school days I’ve taken an interest in learning more languages/ecosystems (e.g., Elixir and Rust). Recently, I’ve taken a renewed interest in Literate Programming. I’m toying with the idea of using it in a somewhat large scale in a future project. It takes a ton of work to do LP right, but in many ways it’s the best possible way to document code (case in point, the absolutely stellar documentation standards of the TeX community, such as the glorious TikZ user manual).
And I believe that readability is the most important attribute when it comes to code — even before correctness! Because at least if the intent of the author is clear, we can have a (fairly) easy way to fix things to make it correct. The other way around (correct, but unreadable code) suffers from stagnation because people become afraid of touching it, because it’s hard to understand. It becomes harder to extend and grow, which is required of any software worth maintaining (we call it software for a reason).
Going back to the question (sorry for rambling a bit there), in my $DAYJOB I work on microservices, APIs, and backend systems. Professionally I’ve always been a backend/infra engineer. In my spare time I contribute to this wonderful community!
-
What would you name your most important contribution to Git?
I would say my contributions to the documentation come out on top. At the end of the day, Git is meant for human consumption. So getting a bit more polish here and there for user-facing docs is well worth the trouble, and I am most proud of my work in this area so far.
If I had more time, I would overhaul the documentation to make things easier to understand. Truly, Git has a very simple conceptual model (thanks to the brilliance of its original author). You just have to understand that commits come from one or more other commits (sort of like family trees). That’s it! But sadly we have a reputation of having absolutely terrible user-facing docs, so much so that it pushed people away to Mercurial and other more friendly VCSs. We need to fix that.
-
What are you doing on the Git project these days, and why?
Last year I started trying to add unit tests to the (perhaps obscure)
git interpret-trailers
command, but this effort has morphed into “let’s also overhaul the entire subsystem around how trailers are handled, with the aim of creating a reusable C library around it” [ ref 1 ] [ ref 2 ].I’m afraid I’ve bitten off more than I can chew, but I do have a backlog of about 60 patches that I need to get sent up for review. Not all at once, of course haha. Hopefully I can get these sent up and merged over the coming months. The review process can be lengthy you see, but for good reason — we take time to try to make sure things are right the first time.
-
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?
At the risk of being unoriginal, it would be libification (see Calvin Wan’s interview from edition 102). But to be more precise, it would be the complete banning of “shelling out” which we do in many places (where Git spawns another Git process to do something). Instead we could (and should) be using libraries internally inside Git’s own codebase. I believe that once we can get Git to start treating itself as a library, that external library consumption will soon follow.
There are many others interested in this area as Git has a massive footprint in our industry. I hope that the many large companies that benefit from Git can grow their roster of Git contributors.
-
If you could remove something from Git without worrying about backwards compatibility, what would it be?
git checkout
. I believegit switch
andgit restore
replaced the need to havegit checkout
. I believe in the “there should be only one way to do the right thing” camp when it comes to the CLI, so I don’t like how we have multiple commands with a lot of overlap.I say this even though personally I’ve been using Git for over 15 years and have always used
git checkout
(even after the introduction ofgit {switch,restore}
). Simplicity matters! -
What is your favorite Git-related tool/library, outside of Git itself?
Tig. I use it all the time, every day. It’s so good that I basically never use
git log
, unless I’m searching through it interactively with the pager.Every time I see someone proudly showing off their latest “git-log” incantation (with all its bells and whistles), I think to myself “I guess they’ve never heard of
tig
”.Being an Emacs user, I tried to get into Magit but could not get used to the keybindings that conflicted with my Vim-styled bindings. (Yes, I use Evil mode via Doom Emacs if you’re into that sort of thing.) OTOH I get so much done with the basic
git-*
commands andtig
that I’m rather happy with my workflow. -
Do you happen to have any memorable experience w.r.t. contributing to the Git project? If yes, could you share it with us?
Nine years ago, I contributed my first patch series. I was so proud of this work that I wrote a blog post about it.
The TL;DR of that post is that anyone can contribute to Git, and really we are a welcoming community. Junio goes out of his way to accommodate new contributors (I admire his patience), so please, feel free to join us!
-
What is your toolbox for interacting with the mailing list and for development of Git?
So my first contribution 9 years ago was via (the traditional)
git send-email
command. These days there is this very neat service called GitGitGadget that allows you to create pull requests on GitHub and does all the housekeeping work of keeping mailing list discussions in sync (you’ll get comments on your PR which come from mailing list responses). Plus you can get previews of your patch series (exactly how they’ll look like on the list) before you submit it, which is always nice.For local Git development, honestly I don’t do anything special or unusual. One window for Emacs, one window for (re)compiling Git and running tests, and maybe one more for Tig. From Emacs I use notmuch to browse the mailing list emails (which I sync to Gmail with lieer).
I use Org mode in Emacs heavily for organizing code snippets and ideas.
Last but not least, I use tmux to organize terminal windows and navigate quickly across them, even if I’m not using SSH.
-
What is your advice for people who want to start Git development? Where and how should they start?
The hard part is figuring out which area you want to work on. Git has a large codebase, so I recommend starting out with documentation changes to familiarize yourself with the current state of things. There’s always a typo or grammofix hiding in there!
Many of our manpages read like dictionaries, when they should read more like user guides. Some manpages have helpful “EXAMPLES” sections to show you how to actually use various options and commands, so if you can think of additional examples, that would be most welcome. Getting familiar with how things work with user-facing docs should help you understand the intent behind the large C codebase we have.
Try to make your contributions as small as possible, but make an effort to write good commit messages. Copy the style of veterans like Junio, Peff (Jeff King), Christian Couder, and others I am forgetting (sorry!) who’ve been doing this for a long time.
Once your change is submitted, nag people weekly to get things moving (yes, we need prodding occasionally). But also don’t get offended if there are a lot of review comments for seemingly small things — we’re just trying to maintain a certain level of quality. Git is used by almost everyone in the software industry, so it’s important for us to keep a high bar for quality, that’s all.
-
If there’s one tip you would like to share with other Git developers, what would it be?
Junio has been our maintainer for nearly two decades. It’s a tough job and somehow he’s kept going at it all this time. Still, let’s do our best to help make his job easier, because honestly we are truly lucky to have someone of his caliber lead our project.
More concretely, this means helping out with code reviews. If you’re not sure which ones to review, see the “What’s Cooking” emails that Junio sends out regularly to look for patches that need help from reviewers. They are commented as “Needs review” or “Comments?”, so they’re easy enough to spot.
Cheers!
Other News
Light reading
- Julia Evans continues her series of blog posts about Git with How HEAD works in git and The “current branch” in git. The first entry in this series of blog posts can be found in Git Rev News Edition #103.
- Keeping repository maintainer information accurate: ensuring that the CODEOWNERS file is up to date with the help of tools like cleanowners. By Zack Koppert on GitHub Blog.
- De Programmatica Ipsum, Issue #66: Version Control - Twenty Years Is Nothing by Adrian Kosmaczewski.
- Git Worktrees and GitButler: How do Git worktrees help you work on more than one branch at the same time, and how does that differ from virtual branches in GitButler? Written by Scott Chacon on GitButler Blog.
- Fixing up [a series of] Git [commits] with Autosquash by Scott Chacon on GitButler Blog.
- Advanced git commands every senior software developer needs to know by Otto Kekäläinen on Optimized by Otto blog.
- Five Ways to Be More Productive with Git
by Paul Redmond on Laravel News blog. The blog post lists
a few useful Git aliases, setting up a commit template, using password manager for SSH keys
(that can be used for signing commits), making use of the GitHub CLI tool (
gh
), and configuringmergetool
anddifftool
. - Git: programmatic staging
(with the help of the
expect
tool, or withgrepdiff
) by Ilia Choly on Choly’s Blog. The author uses described technique as a cleanup step after rewriting/refactoring code using automatic tools, such as Semgrep, ast-grep, LLMs (Large Language Models) such as ChatGPT, and one-off scripts.- Semgrep was mentioned in Git Rev News Edition #75; you can test it with Semgrep Playground.
- Another article
by the same author mentions other similar tools, namely
CodeQL (mentioned in passing
in Git Rev News Edition #79),
and Comby. It also talks about the newly created
semgrepx
tool for rewritingsemgrep
matches using externals tools (such as Datasette’sllm
CLI tool and Python library).
- Unleashing the Power of Git Bisect by Shai Almog on DZone (DevOps Zone).
- Moving Code from One Repository to Another Using Git Patch
by Joel Colaco on his blog - though a better solution would be to use
git format-patch
andgit am
(or alternates andgit cherry-pick
). - Extremely Linear Git History,
with first commit in a repo having a hash that starts with
0000000
, the second commit is0000001
, and so on; written by Gustav Westling on his blog (2022). - Witty.rb - A very simple Ruby Script demonstrating how to parse a Git index file (
.git/index
). Published as Gist by Chubak Bidpaa. -
Dr. Git-Love or: How I Learned to Stop Worrying and Love the Rebase are HTML slides for Git training course by Pablo Vergés (escodebar).
- Toy/demo: using ChatGPT to summarize lengthy LKML threads (b4 integration) thread on Linux kernel mailing list, started by Konstantin Ryabitsev.
Easy watching
- So You Think You Know Git Part 2 - DevWorld 2024 by Scott Chacon on GitButler YouTube channel, continues the FOSDEM version of the talk, which was mentioned in the previous Git Rev News. DevWorld Git Slides are available on GitButler Blog.
Git tools and sites
- extremely-linear, also known as
git-linearize
, is a tool to create commits with SHA-1 identifier beginning with0000000
for the first commit,0000001
for the second,0000002
for the third, and so on. This tool uses lucky_commit, which inserts invisible whitespace characters at the end of the commit message until it gets a SHA-1 (or SHA-256) hash with the desired prefix.- Compare and contrast with git-vain
(mentioned in Git Rev News Edition #103)
and git-vanity-sha
(mentioned in Git Rev News Edition #39),
tools to generate vanity hashes (for example to make the SHA-1 hash of HEAD begin with
c0ffee
).
- Compare and contrast with git-vain
(mentioned in Git Rev News Edition #103)
and git-vanity-sha
(mentioned in Git Rev News Edition #39),
tools to generate vanity hashes (for example to make the SHA-1 hash of HEAD begin with
- Nosey Parker is a command-line program that finds secrets and sensitive information in textual data and Git history. Written in Rust, under Apache 2.0 license.
- gitu - a TUI Git client inspired by Magit. Written in Rust, under MIT license.
- Vim-Flog is a powerful Git branch viewer for Vim. Requires Neovim or Vim with Lua support.
- gcd - Git worktree navigator,
lets you quickly navigate to Git worktrees on your filesystem,
and to directories within your current worktree.
Written as a set of shell functions to be sourced into
~/.zshrc
or~/.bashrc
. - grepdiff is a command-line tool that reads unified diffs from the files passed as arguments (or standard input), and prints a reduced diff containing only the hunks matching a regular expression. Written in Go.
- Gitstr is a tool to send and receive Git patches
over Nostr, using NIP-34.
- Compare and contrast with git-ssb (see git-ssb-intro guide): decentralized Git repo hosting and issue tracking on Secure-ScuttleButt (SSB), mentioned in Git Rev News Edition #26 and #40.
Releases
- libgit2 1.8.0
- Gerrit Code Review 3.7.8, 3.9.2
- GitHub Enterprise 3.12.1, 3.11.7, 3.10.9, 3.9.12, 3.8.17, 3.12.0, 3.11.6, 3.10.8, 3.9.11, 3.8.16
- GitLab 16.10.1, 16.9.3, 16.8.5, 16.10, 16.9.2
- GitKraken 9.13.0
- GitHub Desktop 3.3.12, 3.3.11, 3.3.10
- Tower for Windows 6.0 (Release blog post)
- Tower for Mac 10.5
- git-credential-azure 0.3.0
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 Linus Arver, Eric Sunshine, Ghanshyam Thakkar, Kristoffer Haugsbakk, Štěpán Němec, Junio Hamano and Bruno Brito.