I can use a workaround to continue testing 2.37.2, but I saw in a different mail that there has already been a patch for this problem. I'm guessing that will be in 2.37.4. When would that be likely to be available? Thanks for the quick patch, by the way. .. Lana (lana.deere@xxxxxxxxx) On Thu, Sep 8, 2022 at 2:14 PM Jeff King <peff@xxxxxxxx> wrote: > > On Thu, Sep 08, 2022 at 12:46:14PM -0400, Lana Deere wrote: > > > With an explicit -c protocol.version=0 on the 2.37.2 git command line, > > the pull is successful. For what it's worth, the server git is still > > 2.18.0 in all of these cases. Only the client side is being tested so > > far. I will try to gather the packet traces and see if there's a > > problem sharing them. Will this mailing list allow attachments? > > You can send attachments to the list as long as the total mail size is > under 100kb. But to keep the list in the loop: Lana sent me the traces > off-list, because naturally they have a bunch of semi-private ref names. > > I was able to see the problem from the traces: the v2 protocol has an > extension to tell the server to limit the advertisement only to branches > we're interested in. And it does so based on the configured refspec. As > Dscho noted earlier in the thread, the upstream branch you want isn't in > the refspec. We try to add that branch explicitly to what we're > fetching, but I think that happens too late to affect the ref-prefix > limiting. So the server is asked not to advertise the ref, and from the > client's perspective, it looks like the branch does not exist on the > server. > > Here's a minimal reproduction: > > # a server with two branches > git init server > ( > cd server > git checkout -b branch1 > git commit --allow-empty -m foo > git branch branch2 > ) > > # and a client which points its origin there, > # and has local copies of both branches, tracking > # the upstream versions > git clone server client > cd client > git checkout branch1 > git checkout branch2 > > # but afterwards, the client narrows its refspec to only fetch branch1 > git config remote.origin.fetch +refs/heads/branch1:refs/remotes/origin/branch1 > > # pulling branch2 with v0 works > git -c protocol.version=0 pull > > # but does not with v2, because the ref-prefix extension tells the > # server not to advertise anything outside of branch1 > git -c protocol.version=2 pull > > This is a bug which we should fix. But in the meantime the obvious > workaround is to expand the default refspec to cover both branches. > Obviously the default of fetching "refs/heads/*" would work, but if you > want to keep it limited for some reason, you can add the second branch > explicitly. In the example above, it would be: > > git config --add remote.origin.fetch +refs/heads/branch2:refs/remotes/origin/branch2 > > -Peff
