Welcome to the 101st 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 June 2023 and July 2023.
[ANNOUNCE] Virtual Contributor’s Summit 2023
Taylor Blau from GitHub announced that GitHub will host a Virtual Contributor’s Summit this year. Previously he announced that there would be no Git Merge in-person event this year.
The announce of the Virtual Contributor’s Summit 2023 contained links for participants to register, to suggest topics and to vote on proposed topics.
[RFC PATCH 0/8] Introduce Git Standard Library
Calvin Wan sent a 8 patch long RFC series to the mailing list to introduce a “Git Standard Library”. This new library was intended to be a base library for other Git libraries to build upon.
This followed previous effort from Calvin and Elijah Newren to
cleanup headers
and internal APIs like the
strbuf API
to manipulate character strings and the
git-compat-util API
to provide wrapper compatibility functions masking OS differences.
It also followed previous
discussions about turning parts of Git into libraries
and the ongoing
video conferences
that are regularly hosted by Google about libifying Git.
Building Git already involves creating an internal library called
libgit.a that contains a lot of common code used by many Git
commands. The Git executable is then created by linking all the
object files for the Git subcommands (like git log) and the git
command itself against libgit.a and a few external
dependencies. The goal with the new Git Standard Library, also
called git-std-lib.a, and the Git libification effort is to have a
number of small independent libraries (like object-store.a, and
config.a) all using git-std-lib.a. These small independent
libraries would also be linked together to form libgit.a, which
would then be used to create the Git executable like today. The
benefit would be that “if someone wanted their own custom build of
Git with their own custom implementation of the object store, they
would only have to swap out object-store.a rather than do a hard
fork of Git”.
The new Git Standard Library is considered necessary for the
libification effort, because there are numerous circular and
ubiquitous dependencies that are very difficult to untangle and it
probably wouldn’t be worth untangling them. As the libification
effort doesn’t promise stability of interfaces though, it would
still be possible to extract some small libraries from
git-std-lib.a later if there is ever a need to be able to swap
them out.
Calvin noted that a pitfall of this series was the introduction of
#ifdef GIT_STD_LIB preprocessor instructions to stub out some code
and hide some function headers. He asked for comments about how it
would be possible to avoid those instructions which make the code
harder to understand. He also mentioned that some of the
compatibility code in compat/ still had dependencies outside
git-std-lib.a, but that it just meant that “some minor
compatibility work” might be needed in the future.
As to the testing of the new library, he said that “the temporary test file added by the series will be replaced with unit tests once a unit testing framework is decided upon”, pointing to the related discussion. That discussion is actually an RFC patch series that in its latest version only adds an asciidoc document explaining the plan to add a unit test framework to Git and containing a table comparing the possible unit test frameworks that Git could adopt.
Victoria Dye and then Jeff Hostetler replied to the first patch in
Calvin’s series saying that they didn’t agree with the fact that the
Trace2 code wouldn’t be in git-std-lib.a. They pointed out that it
should be possible to use the Trace2 tracing functions everywhere in
the Git code, even in low-level functions. Calvin replied that he
would look into possible solutions like redrawing the boundaries of
the library or stubbing out tracing in it to accommodate that need.
Phillip Wood commented on a few patches saying he liked the idea, but suggested that the library should also contain the code related to gettext and to some basic data structures (“hashmap.c” and “string-list.c”). He also suggested some improvements and a way to deal with the Trace2 issue.
Junio Hamano, the Git maintainer, was happy that one patch removed the dependency many files had on “config.c”. He wondered though if another patch that removed a wrapper function to remove a dependency did the right thing, as the function had a number of callers. Glen Choo then chimed in to suggest an alternative way to remove that dependency and both Calvin and Junio agreed that this would be a good way forward.
Glen separately reported that he had trouble building the series. Calvin clarified that the series was based on Git v2.41 and sent a link to the code.
Linus Arver also replied to Calvin’s series by asking a number of questions. He wondered if adding the standard library would make it harder or not to refactor code into separate libraries or to create separate programs that would use only some Git API, like for example the API in “trailer.c” that helps parse commit message trailers (e.g. “Signed-off-by: Author Name author@example.com). He asked for more information about the tradeoffs between accepting the circular dependencies and untangling them, and made a number of other suggestions.
It’s not clear yet if the libification effort and the idea of a Git Standard Library will bring a lot of changes to the code base soon, but that could be an interesting possibility.
Who are you and what do you do?
I’m Martin Ågren. I live in Sweden, where I spend some of my spare time in the garden or tending to the bees to the best of my abilities. I also enjoy reading books and listening to music (not at the same time).
What would you name your most important contribution to Git?
The number of breathtaking features I’ve contributed is probably a one-digit number ending in a zero. That said, I think I’ve contributed a bit to the documentation by fixing some fairly ugly misrenderings, but also by aligning the way it’s formatted by the two tools we support, asciidoc and asciidoctor. I guess we’ll never know this for a fact, but there’s a chance that I’ve saved someone’s crontab by fixing a bug that would eat it. I’m very happy that I fixed that bug before it was ever included in a release.
What are you doing on the Git project these days, and why?
I’m mostly just tinkering. I very rarely feel like there’s something actually missing from Git. I’m mostly trying to contribute in order to show that gratitude and to help others, without occupying too much bandwidth.
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?
Complete the hash function transition. brian m. carlson has done a tremendous job making sure there are these two parallel worlds, if you want. What’s missing now is making them interoperable. This is not necessarily the biggest problem in current Git, but it could be something that won’t be fixed by short-term, this-quarter, profit-maximizing actors, so if I could decree a team to work on that without having to worry about “return on investment” and such, I’d probably go for that.
If you could provide users of Git with one piece of advise, what would it be?
The one thought I would like to somehow convey to everyone using Git is
to commit early, commit often. Whatever crap you have ever had in your
working tree, there’s an object containing it. Use git reset --hard,
git rebase, git cherry-pick, whatever floats your boat, you will be
able to bring it back and polish it up into a Git history that looks
like you knew what you were doing all along.
I think this is really the point about Git: it teaches you how to pretend to be a good programmer, and once you start thinking of shaping your work like that, you actually might turn into one. Not because “fake it till you make it”, that’s just bullshit, but because you actually spend time approaching problems the right way and start thinking about how you present your solution.
Your “solution” is then not just the state of the working tree (“look! it compiles and all the tests pass, so it must be good!”), but also how you got there, as a series of well-motivated incremental changes.
What is your favorite Git-related tool/library, outside of Git itself?
I’m a big fan of tig, especially tig blame. I simply never use git
blame. If I’m allowed to count git/contrib as “outside of Git
itself”, I’ll be more than happy to recommend git jump. It’s not
especially sexy, but I probably use it every single day and I find it
extremely helpful.
Do you happen to have any memorable experience w.r.t. contributing to the Git project? If yes, could you share it with us?
I still sometimes think back to when I posted my first patch series to the list. Peff wrote “[…] I’m very impressed with the attention to detail for a first-time contributor.”, to which Junio replied “Yes.”. Of course, a part of even remembering that is vanity on my part, but I do think those two sentences are fairly representative of each of their communication styles. They also capture perfectly well the kind of review style that I wish a lot more projects used. You know, it is allowed to not just point out something that is wrong or could be better.
What is your toolbox for interacting with the mailing list and for development of Git?
For the list, it’s gmail.com, lore.kernel.org/git, git am, git format-patch,
and git send-email. I keep thinking I should set up something
more advanced, but for the limited volumes I’m handling, it’s fine. For
development of Git [and other stuff], it’s Vim, git diff, git add -p,
git commit --amend, git rebase -i, git range-diff, tig blame,
git jump (grep, merge, diff) and … maybe that’s about it. Well, git show
and git log of course. Please note the -p in git add -p. I would like
to live in a world where no-one blindly does git add . && git commit.
What is your advice for people who want to start Git development? Where and how should they start?
Do something you enjoy doing. Of all the people born any given year, not even one of them, on average, will ever become president of the United States. Don’t do open source because it could land you a nice job somewhere, sometime. Don’t do Git development because it seems like a good investment. Do open source because you believe in it and see some random thing that you want to contribute to. If you don’t see that, plant a flower instead and watch it grow.
This obviously comes from someone who is privileged enough to be able to say “don’t worry, be happy” and talk in metaphors about gardening. That said, I do think there’s a difference in keeping bees and tending to them. You shouldn’t want to keep them, you should want to help them do their thing. And if you want to help Git do its thing, great!
Start by lurking on the mailing list to get a feel for how it works. Then do some small improvement, and avoid growing the scope too much. Sleep on your patch, review it yourself and iterate that process a few times before actually sending it off.
Various
Light reading
git replay command.
Merge commits were created using the merge-ort strategy
on GitHub since September 2022, as mentioned in Git Rev News Edition #91.Easy listening
Git tools and sites
git add an ignored file, etc.).
Written in Python.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 Eren Canpolat, Bruno Brito, Kristoffer Haugsbakk, Junio Hamano and Štěpán Němec.