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

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

This is the final output from git bisect:

$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[d8d3d632f4165955da49032d50279c20cfbde2e5] hooks--update.sample: use
hash-agnostic zero OID

Does that offer any hint about what is going on?

Incidentally, some but not all of the pulls produced additional
output.  Maybe it's a clue?

$ ~/tmp/git/install/bin/git pull
warning: Pulling without specifying how to reconcile divergent branches is
discouraged. You can squelch this message by running one of the following
commands sometime before your next pull:

  git config pull.rebase false  # merge (the default strategy)
  git config pull.rebase true   # rebase
  git config pull.ff only       # fast-forward only

You can replace "git config" with "git config --global" to set a default
preference for all repositories. You can also pass --rebase, --no-rebase,
or --ff-only on the command line to override the configured default per
invocation.

From http://githost:7990/scm/dp/d2s_sw
 * branch                  feature/switch-to-qt5 -> FETCH_HEAD
Already up to date.


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

On Fri, Sep 2, 2022 at 9:07 PM Jeff King <peff@peff.net> wrote:
>
> On Fri, Sep 02, 2022 at 03:27:55PM -0400, Lana Deere wrote:
>
> > I'm testing an upgrade to git 2.37.2 from the current version we're
> > using of 2.18.0.  When I try to pull in my development tree, 2.37.2
> > gives me an error but 2.18.0 things all is fine:
> >
> > $ /tools/linux-x86_64/git/2.37.2/bin/git pull
> > Your configuration specifies to merge with the ref
> > 'refs/heads/feature/switch-to-qt5'
> > from the remote, but no such ref was fetched.
> >
> > $ /tools/linux-x86_64/git/2.18.0/bin/git pull
> > From http://githost:7990/scm/dp/sw
> >  * branch                  feature/switch-to-qt5 -> FETCH_HEAD
> > Already up to date.
> >
> > Anyone have any ideas about this?  All I could find on google was a
> > suggestion that the "no such ref" message indicates the remote branch
> > was deleted, but that's not the case here.
>
> It's curious that the older version shows us fetching into FETCH_HEAD,
> but the new one doesn't. I wonder if you have some unusual refspecs. Or
> perhaps a branch.*.remote config option which fetches from a different
> remote. The "git config" output brian asked for may be instructive
> there.
>
> If it's possible for you to build Git from source, it may also be
> interesting to bisect to find the commit that caused the change.
>
> -Peff