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? .. Lana (lana.deere@xxxxxxxxx) On Wed, Sep 7, 2022 at 5:10 PM Jeff King <peff@xxxxxxxx> wrote: > > On Wed, Sep 07, 2022 at 02:53:37PM -0400, Lana Deere wrote: > > > OK, I tried the bisect again. I used the bin-wrappers/git from my git > > source each time I did a pull and each time I did a bisect. This time > > the final result was indeed different: > > > > $ ~/tmp/git/git/bin-wrappers/git bisect bad > > eb049759fb6b739310af52ee0e13ce6cd0c86be7 is the first bad commit > > commit eb049759fb6b739310af52ee0e13ce6cd0c86be7 > > Author: Jeff King <peff@xxxxxxxx> > > Drat, I shouldn't have helped you figure out I was the culprit. ;) > > > protocol: re-enable v2 protocol by default > > OK, so this is definitely a plausible bisection result. Things shouldn't > behave any different between the two protocols, but there could be a > bug. > > The first thing I'd try is whether: > > .../git/2.37.2/bin/git -c protocol.version=0 pull > > works like 2.18.0 does. If so, then that confirms that protocol v2 is > the problem. At that point I might try capturing packet dumps with: > > GIT_TRACE_PACKET=/tmp/v0.trace \ > .../git/2.37.2/bin/git -c protocol.version=0 pull > > GIT_TRACE_PACKET=/tmp/v2.trace \ > .../git/2.37.2/bin/git -c protocol.version=2 pull > > They'll be sufficiently different that you can't just diff them, but if > you're able to share them, one of us familiar with the protocol might be > able to notice something. > > I don't _think_ there should be a problem with the server side of your > connection speaking the v2 protocol. After all, you found that the > ls-remote output was the same for both versions. > > -Peff
