advertised commit fetch using commit id fails

Hello,

git 2.22, in contrast to previous versions, fails to fetch advertised commit using commit id:

$ git --version git version 2.22.0

$ git init git $ git -C git remote add origin https://github.com/git/git

$ git ls-remote https://github.com/git/git | grep v2.21 2bb64867dc05d9a8432488ddc1d22a194cee4d31 refs/tags/v2.21.0 8104ec994ea3849a968b4667d072fedd1e688642 refs/tags/v2.21.0^{} e4be0477c7bd475c863a361d7d8aeaeab621606c refs/tags/v2.21.0-rc0 d62dad7a7dca3f6a65162bf0e52cdf6927958e78 refs/tags/v2.21.0-rc0^{} 8b301c10ed2bc973cec4f8395dec90fce2df42fb refs/tags/v2.21.0-rc1 8989e1950a845ceeb186d490321a4f917ca4de47 refs/tags/v2.21.0-rc1^{} 1c668b7b88be5f46f8dc8fe403842cdc663185d9 refs/tags/v2.21.0-rc2 35ee755a8c43bcb3c2786522d423f006c23d32df refs/tags/v2.21.0-rc2^{}

$ git -C git fetch origin 8104ec994ea3849a968b4667d072fedd1e688642 error: Server does not allow request for unadvertised object 8104ec994ea3849a968b4667d072fedd1e688642

Fetching using tag id still works:

$ git -C git fetch origin 2bb64867dc05d9a8432488ddc1d22a194cee4d31
remote: Enumerating objects: 255575, done.
remote: Total 255575 (delta 0), reused 0 (delta 0), pack-reused 255575
Receiving objects: 100% (255575/255575), 107.95 MiB | 2.34 MiB/s, done.
Resolving deltas: 100% (190845/190845), done.
 From https://github.com/git/git
  * branch            2bb64867dc05d9a8432488ddc1d22a194cee4d31 -> FETCH_HEAD

Fetching using commit id that is a tip of some branch works also:

$ git ls-remote https://github.com/git/git | grep b697d92f56511e804b8ba20ccbe7bdc85dc66810 b697d92f56511e804b8ba20ccbe7bdc85dc66810 refs/heads/maint b697d92f56511e804b8ba20ccbe7bdc85dc66810 refs/tags/v2.22.0^{}

$ git -C git fetch origin b697d92f56511e804b8ba20ccbe7bdc85dc66810
remote: Enumerating objects: 260471, done.
remote: Total 260471 (delta 0), reused 0 (delta 0), pack-reused 260471
Receiving objects: 100% (260471/260471), 112.66 MiB | 2.33 MiB/s, done.
Resolving deltas: 100% (194715/194715), done.
 From https://github.com/git/git
  * branch            b697d92f56511e804b8ba20ccbe7bdc85dc66810 -> FETCH_HEAD

Note that the git version at the tip of the master branch (2.22.0.68.g0aae918dd9) behaves the same way.

git 2.21 fetches fine:

$ git --version git version 2.21.0

$ git -C git fetch origin 8104ec994ea3849a968b4667d072fedd1e688642
remote: Enumerating objects: 255574, done.
remote: Total 255574 (delta 0), reused 0 (delta 0), pack-reused 255574
Receiving objects: 100% (255574/255574), 107.95 MiB | 2.15 MiB/s, done.
Resolving deltas: 100% (190845/190845), done.
 From https://github.com/git/git
  * branch            8104ec994ea3849a968b4667d072fedd1e688642 -> FETCH_HEAD

Is it a bug or advertised object semantics change?

Best regards, Karen

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

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

On Fri, Jun 14, 2019 at 11:27:10AM -0400, Jeff King wrote:

I'd add that in protocol v2, the reachability restrictions are lifted (i.e., every server behaves as if uploadpack.allowAnySHA1InWant is enabled). So you could probably just set protocol.version=2 on your client. This will eventually becomes the default, too.

-Peff