* advertised commit fetch using commit id fails
@ 2019-06-14 10:54 Karen Arutyunov
2019-06-14 15:27 ` Jeff King
0 siblings, 1 reply; 3+ messages in thread
From: Karen Arutyunov @ 2019-06-14 10:54 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: advertised commit fetch using commit id fails
2019-06-14 10:54 advertised commit fetch using commit id fails Karen Arutyunov
@ 2019-06-14 15:27 ` Jeff King
2019-06-14 15:29 ` Jeff King
0 siblings, 1 reply; 3+ messages in thread
From: Jeff King @ 2019-06-14 15:27 UTC (permalink / raw)
To: Karen Arutyunov; +Cc: git
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: advertised commit fetch using commit id fails
2019-06-14 15:27 ` Jeff King
@ 2019-06-14 15:29 ` Jeff King
0 siblings, 0 replies; 3+ messages in thread
From: Jeff King @ 2019-06-14 15:29 UTC (permalink / raw)
To: Karen Arutyunov; +Cc: git
On Fri, Jun 14, 2019 at 11:27:10AM -0400, Jeff King wrote:
> 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.
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-06-14 15:29 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-06-14 10:54 advertised commit fetch using commit id fails Karen Arutyunov
2019-06-14 15:27 ` Jeff King
2019-06-14 15:29 ` Jeff King
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).