On Mon, Aug 18, 2025 at 05:03:12PM -0400, Jeff King wrote: > When describing a blob, we traverse from HEAD, remembering each commit > we saw, and then checking each blob to report the containing commit. > But if we haven't seen any commits at all, we'll segfault (we store the > "current" commit as an oid initialized to the null oid, causing > lookup_commit_reference() to return NULL). > > This shouldn't be able to happen normally. We always start our traversal > at HEAD, which must be a commit (a property which is enforced by the > refs code). But you can trigger the segfault like this: > > blob=$(echo foo | git hash-object -w --stdin) > echo $blob >.git/HEAD > git describe $blob I bet that the enforcement is only of partial nature, and that there are ways to do the above e.g. via git-update-ref(1) or by playing around with symrefs. [snip] > I didn't include a test here because it requires corrupting the > repository in a way that is only easy to do using the files ref backend. > It doesn't seem worth carrying a REFFILES test just for this oddity. True: $ git update-ref HEAD HEAD^{tree} fatal: update_ref failed for ref 'HEAD': trying to write non-commit object 4b825dc642cb6eb9a060e54bf8d69288fbee4904 to branch 'HEAD' But: $ git update-ref refs/some/tree HEAD^{tree} $ git symbolic-ref HEAD refs/some/tree $ git show tree HEAD So that should allow you to write a test, right? Patrick