Re: 2.37.2 can't "git pull" but 2.18.0 can

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@gmail.com)



On Wed, Sep 7, 2022 at 5:10 PM Jeff King [off-list ref] wrote:

On Wed, Sep 07, 2022 at 02:53:37PM -0400, Lana Deere wrote:

quoted

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 [off-list ref]

Drat, I shouldn't have helped you figure out I was the culprit. ;)

quoted

    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