Re: [PATCH v3 2/2] odb: ignore refs of shallow and grafted alternates

From: Patrick Steinhardt <ps@pks.im>
Date: Oct 23, 2026, 10:43 UTC
Message-ID: <ats6VLXUqKwKZzIY@pks.im>
In-Reply-To: <20261019110918.71193-3-iwiedler@gitlab.com>

On Mon, Oct 19, 2026 at 01:09:18PM +0200, Igor Wiedler wrote:

Show 7 quoted lines

> odb_for_each_alternate_ref() reports the refs of every alternate
> object store that is a repository. Its three callers use them as
> commits whose history can be assumed to be present: "rev-list
> --alternate-refs" (and through it the connectivity check after a
> fetch), fetch-pack, which sends them as "have"s so that the server
> does not resend what the alternate has, and receive-pack, which
> advertises them as ".have".

Right, for all of these three callers it doesn't make any sense to advertise those haves in case the repository is shallow. It's a somewhat funny setup to have shallow alternates, but in case anybody does, this change here would avoid a potentially corrupted repository.

Show 7 quoted lines

> That assumption does not hold for a shallow repository, whose refs
> point at commits with no history behind them below its shallow
> boundary, nor for a grafted one. A repository borrowing objects from
> such an alternate does not see the alternate's shallow file, so the
> history that is missing there is missing here as well. The fetch then
> succeeds, the connectivity check stops at the alternate's refs, and
> a later "git log" fails with "Could not read <oid>".

Yup.

Show 10 quoted lines

> "git clone --reference" already rejects a shallow or grafted
> reference repository for this reason, but nothing prevents such a
> repository from being added via objects/info/alternates or
> GIT_ALTERNATE_OBJECT_DIRECTORIES, or from being made shallow after
> other repositories started borrowing from it.
> 
> Skip the refs of an alternate that has a "shallow" file or an
> "info/grafts" file, the same checks clone uses. Its objects are still
> available through the object store. Only its refs are no longer used
> as a boundary.

It could of course be that somebody manually created such a repository and due to some obscure reason still expects "--alternate-refs" to work. But I feel like this use case is sufficiently unlikely to simply not matter in practice, and the fact that Git refuses creating this setup in the first place is a good indicator that nobody will care about this change.

I feel like the whole concept of alternate refs is quite flawed in the first place. We get as input an object directory and then we hope that its parent directory _may_ be a proper repository.

Other than that this looks good to me, thanks!

Patrick