Re: advertised commit fetch using commit id fails

From: Jeff King <peff@peff.net>
Date: Jun 14, 2019, 15:27 UTC
Message-ID: <20190614152710.GB22984@sigill.intra.peff.net>
In-Reply-To: <38030a81-73bc-f877-362a-3fd8018b5977@codesynthesis.com>

On Fri, Jun 14, 2019 at 01:54:15PM +0300, Karen Arutyunov wrote:

> git 2.22, in contrast to previous versions, fails to fetch advertised commit
> using commit id:
>
> Is it a bug or advertised object semantics change?

This is working as designed, but the behavior is a rather tricky historical case. The change you're seeing is due to 34066f0661 (fetch: do not consider peeled tags as advertised tips, 2019-04-13), and there's further discussion in the thread at:

  https://public-inbox.org/git/20180610143231.7131-1-kirr@nexedi.com/

Basically, upload-pack has never considered the peeled value of a tag to be "advertised" for the purposes of letting the client request it. But by default, in git-over-http mode, the server does act as if uploadpack.allowReachableSHA1InWant is set, which comes from 051e4005a3 (helping smart-http/stateless-rpc fetch race, 2011-08-05).

So even though the server does not advertise that it will accept non-tip sha1s, it happened to do so only over this one protocol. If you retry your fetch over git:// or ssh, it would fail with any version.

It would also fail even with http for versions prior to v2.14, because the bug to consider peeled tips as advertised on the client side comes from fdb69d33c4 (fetch-pack: always allow fetching of literal SHA1s, 2017-05-15).

So in short, it was never supposed to work, but between bugs and protocol vagaries, there are a few version and protocol combinations where it did.

-Peff