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
