Re: [PATCH 4/5] describe: handle blob traversal with no commits

From: Patrick Steinhardt <ps@pks.im>
Date: Aug 19, 2025, 08:05 UTC
Message-ID: <aKQwP01nulsquhzi@pks.im>
In-Reply-To: <20250818210312.GD1024556@coredump.intra.peff.net>

On Mon, Aug 18, 2025 at 05:03:12PM -0400, Jeff King wrote:

Show 13 quoted lines

> 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