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

[Lana Deere <lana.deere@gmail.com>]

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@peff.net>
Date:   Fri Sep 25 14:34:36 2020 -0400

    protocol: re-enable v2 protocol by default

    Protocol v2 became the default in v2.26.0 via 684ceae32d (fetch: default
    to protocol version 2, 2019-12-23). More widespread use turned up a
    regression in negotiation. That was fixed in v2.27.0 via 4fa3f00abb
    (fetch-pack: in protocol v2, in_vain only after ACK, 2020-04-27), but we
    also reverted the default to v0 as a precuation in 11c7f2a30b (Revert
    "fetch: default to protocol version 2", 2020-04-22).

    In v2.28.0, we re-enabled it for experimental users with 3697caf4b9
    (config: let feature.experimental imply protocol.version=2, 2020-05-20)
    and haven't heard any complaints. v2.28 has only been out for 2 months,
    but I'd generally expect people turning on feature.experimental to also
    stay pretty up-to-date. So we're not likely to collect much more data by
    waiting. In addition, we have no further reports from people running
    v2.26.0, and of course some people have been setting protocol.version
    manually for ages.

    Let's move forward with v2 as the default again. It's possible there are
    still lurking bugs, but we won't know until it gets more widespread use.
    And we can find and squash them just like any other bug at this point.

    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

 Documentation/config/feature.txt  | 4 ----
 Documentation/config/protocol.txt | 3 +--
 protocol.c                        | 6 +-----
 3 files changed, 2 insertions(+), 11 deletions(-)


.. Lana (lana.deere@gmail.com)


On Wed, Sep 7, 2022 at 2:21 PM Jeff King <peff@peff.net> wrote:
>
> On Wed, Sep 07, 2022 at 11:56:27AM -0400, Lana Deere wrote:
>
> > Sorry, I was confused by the "0 left".  With one more besect it says
> >
> > 9f489ac6bbb755fa4c83289e44cad12f3b765d69 is the first bad commit
> >
> > That appears to be
> >  [9f489ac6bbb755fa4c83289e44cad12f3b765d69] Merge branch 'dl/zero-oid-in-hooks'
>
> That seems unlikely to be the real culprit. I wonder if something went
> wrong during the bisect.
>
> A common gotcha when building Git from source is to directly run:
>
>   /path/to/git-clone/git pull
>
> Under the hood git-pull will run git-fetch, which it will look for in
> the installed libexec dir. But of course if you didn't run "make
> install", then what is there may be some old version installed
> previously. Instead, you want to run:
>
>   /path/to/git-clone/bin-wrappers/git pull
>
> which will set up the environment so that we'll find any other git
> commands inside the build directory.
>
> That's all a wild guess, of course, but if you think that might be the
> problem it's worth trying the bisect again.
>
> -Peff