Skip to content

2021-09-30-edition-79.markdown

Latest commit

 

History

History
268 lines (214 loc) · 14.4 KB

2021-09-30-edition-79.markdown

File metadata and controls

268 lines (214 loc) · 14.4 KB
title Git Rev News Edition 79 (September 30th, 2021)
layout default
date 2021-09-30 12:06:51 +0100
author chriscool
categories
news
navbar false

Git Rev News: Edition 79 (September 30th, 2021)

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.

Discussions

General

Support

  • bug in git fsck?

    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.

Developer Spotlight: Josh Steadmon

  • 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.

Releases

Other News

Various

Light reading

Git tools and sites

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 Josh Steadmon, Elijah Newren and Philip Oakley.