Welcome to the 79th 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 month of August 2021.
GSoC (Google Summer of Code) 2021 End
Congratulations to the two students who had been accepted to work on Git as part of the GSoC 2021 as they successfully passed all the evaluations!
Atharva Raykar worked on the Finish converting submodule to builtin project. He was co-mentored by Shourya Shukla and Christian Couder. He posted 2 final blog posts about it, some Reflections on Working With the Git Community and a Technical Report.
ZheNing Hu worked on the
Use ref-filter formats in git cat-file
project. He was co-mentored by Hariom Verma and Christian Couder and posted
a final blog post about it.
Last July, Ulrich Windl asked the mailing list whether git fsck
should be able to cleanup orphaned branches. He pointed to
a question he asked on StackOverflow
as he wanted to get rid of obsolete branches after filtering a repo.
git fsck was complaining about a branch called bitmap-generic
saying notice: HEAD points to an unborn branch (bitmap-generic),
because that branch was pointing to a commit that didn’t exist
anymore after filtering the repo, and he couldn’t delete that branch
as git branch -d errored out with fatal: Couldn't look up commit
object for HEAD.
Junio Hamano replied to Ulrich that “HEAD pointing at an unborn branch is not even a corruption”, as that’s what happen to the default branch when a repo is initialized.
Ulrich replied that he might have been confused by git fsck and
suggested updating the documentation to explain what “unborn”
means. Ævar Arnfjörð Bjarmason then agreed with Ulrich that “fsck’s
error messages/reporting is pretty bad”. He said that he had been
working on it though.
Meanwhile René Scharfe replied to Junio saying that git branch -D
(-D is a shortcut for --delete --force) should delete a branch
pointing to an unexisting commit, instead of requiring users to
first reset the branch to some known commit using
git branch --force and then to delete it with git branch --delete.
In this reply René even provided a patch called “branch: allow deleting
dangling branches with --force” that implemented what he suggested.
Ulrich and René then discussed how to actually force a branch in a way
that it can then be deleted. The issue was that Ulrich tried to
force the dangling branch, using git branch --force bitmap-generic
when the current branch wasn’t a valid one, so the dangling branch
wasn’t restored to a valid commit.
To René’s patch, Junio replied that he felt the filtering process Ulrich used shouldn’t have left dangling branches hanging around in the first place. He agreed though that it should be easy to recover from “such a deliberate repository corruption”.
René’s patch then fell through the cracks for several weeks, until the end of August when René resent it.
Junio replied that the test in René’s patch went “against the
spirit” of a recently merged patch series by Han-Wen Nienhuys that
was preparing tests for the new reftable ref backend.
The reftable backend was initially proposed and developed in 2017 by Shawn Pearce. An implementation of it has then been integrated in JGit, and Han-Wen has been working for some time on versions of this backend for Git and libgit2.
Junio suggested to change parts of the test that were creating or
testing refs to use higher functions to manipulate refs, instead of
directly manipulating loose ref files like
.git/refs/heads/dangling.
Junio, Ævar, Han-Wen, Ulrich and René then discussed different ways
to change the test, like using the REFFILES test
prerequisite. They wondered if such a dangling ref could also happen
with the reftable backend, and it seemed that this could indeed
happen.
Han-Wen suggested the ref-store test-helper’s update-ref command
to manipulate refs instead. Ulrich proposed implementing a new
--disarm-safety-belt option to disable checks for testing
purposes. Ævar suggested a workaround using an alternate object
directory.
Meanwhile Ævar commented a bit on René’s resent patch. And René
replied to the comments, especially noting that git tag -d would
delete a dangling tag even without --force.
René then sent a version 2 of his resent patch with an updated test that was now independent from any ref backend.
Junio, Ævar and René discussed the patch a bit more, after which René sent a version 3 with a few more improvements to the test.
As this version of the patch has since been merged into the master branch, Git will soon allow to delete dangling branches more easily.
Who are you and what do you do?
I’m a Software Engineer at Google, and I work on a team dedicated to Git. Outside of work, I’m a husband and a new dad, which doesn’t leave me much time for anything else :).
Git is actually my first experience as a professional developer. Up until I joined the Git team in 2018, my career had been in system administration and reliability engineering.
What would you name your most important contribution to Git?
Probably the addition of fuzz tests. Not so much due to impact so far (although it has found a few small bugs), but because of the opportunity for future work in this area. If I had more time, I’d love to look into having a proper fuzz tester for client/server communication, for example.
What are you doing on the Git project these days, and why?
Until recently, the majority of my work has been internal performance monitoring of Git usage by Google developers. Lately I’ve been winding down my work on monitoring and starting to look into improving performance and the user experience with submodules. Only the very beginnings of that have started to show up on-list so far.
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?
I think I’d echo my former coworker Brandon Williams (edition 28), and work on cleaning up the global state. For a new-ish developer who doesn’t have full history on all the various subsystems, it can be difficult to follow the logic when there’s lots of non-local state being modified.
If you could remove something from Git without worrying about backwards compatibility, what would it be?
Not so much to remove as change: I wish it was easier to move away from SHA-1 hashes. I’m very happy that brian m. carlson has been working on supporting SHA-256.
What is your favorite Git-related tool/library, outside of Git itself?
I’m a huge fan of git-annex and use it to keep my ever-growing pile of PDFs and ebooks synced and organized across various devices. I also use it to archive primary sources in a homebrew personal knowledge base.
Various
Light reading
git commit with Overcommit Gem
by Prabin Poudel on his blog. Overcommit gem
was mentioned in Git Rev News #63,
along various other hook management tools.Git Log Fully Explained.Git tools and sites
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 Josh Steadmon, Elijah Newren and Philip Oakley.