Re: [PATCH] read-cache: avoid sparse-index expansion for unborn HEAD

From: Elijah Newren <newren@gmail.com>
Date: Aug 7, 2026, 15:33 UTC
Message-ID: <CABPp-BHLaW6_CxMdPQURN7zMK1p7dEkihFMAkyWvcd2+j7gJqw@mail.gmail.com>
In-Reply-To: <CAP=WS+sp74WQ=xndQ+2a6W-qP3Zz8=bVnEymgVpS+gwMv1Dh7g@mail.gmail.com>

On Fri, Aug 7, 2026 at 1:05 AM Sahitya Chandra <sahityajb@gmail.com> wrote:

Show 16 quoted lines

>
> On Fri, Aug 7, 2026 at 12:17 PM Elijah Newren <newren@gmail.com> wrote:
> >
> > This explains what, but not why. It feels like a pedagogical exercise
> > with no actual utility.
>
> You are right, I found this through the TODO comment and do not have a
> concrete user bug report or use case driving it.
>
> > Why would someone with an unborn HEAD be using a sparse index? [...]
>
> I do not have a good answer to that. My thinking was simply that
> removing the special-case fallback still has some value: it deletes a
> long-standing TODO, unifies the unborn-branch path with the normal diff
> path, and removes an ensure_full_index() call that future readers would
> need to reason about.

Ah, thanks for looking through the code for TODOs and trying to clean them up. That's noble.

If you submit a v2, it's probably worth just being upfront about this in the commit message -- that we don't expect this to be used in practice, but it makes sense both (a) to remove one more TODO, and (b) because it provides a net reduction in lines of code in read-cache.c.

Show 5 quoted lines

> > This seems to presume a single dirty file, otherwise wouldn't the
> > printing look pretty odd?
>
> I agree that "dirty=%s" looks wrong when multiple paths are
> present. I can fix that in v2.

:-)

I'm curious if the unittesting harness could help here and avoid the need for the test helper changes. Is that possible? (I don't actually know much about the unittesting harness abilities, so I'm genuinely curious).

> Thanks for the review.

Thanks for contributing!