On Fri, Nov 26, 2021 at 1:45 PM Jeff King <peff@xxxxxxxx> wrote:
>
> On Fri, Nov 26, 2021 at 04:44:52PM -0500, Jeff King wrote:
>
> > +cc Alex and Elijah from the original 3d5fc24dae (pull: abort if
> > --ff-only is given and fast-forwarding is impossible, 2021-07-21) in
> > case they have further thoughts, but I _think_ this is working as
> > designed.
>
> Whoops, forgot the cc. Original message in full below.
I believe this was already fixed in 2.34.1 in commit ea1954af77
("pull: should be noop when already-up-to-date", 2021-11-17).
> > On Fri, Nov 26, 2021 at 09:05:46PM +0300, Dmitry Marakasov wrote:
> >
> > > * Jeff King (peff@xxxxxxxx) wrote:
> > >
> > > > > After update from 2.33.0 to 2.33.1 the pull.rebase = true option
> > > > > no longer works: `git pull` no longer tries to rebase (however manual
> > > > > `git pull --rebase` works fine):
> > > > >
> > > > > % git config pull.rebase
> > > > > true
> > > > > % git pull
> > > > > fatal: Not possible to fast-forward, aborting.
> > > > > % git pull --rebase
> > > > > Successfully rebased and updated refs/heads/local-fixes.
> > > > > % git pull
> > > > > fatal: Not possible to fast-forward, aborting.
> > > > > % grep -C1 rebase .git/config
> > > > > [pull]
> > > > > rebase = true
> > > > > [rebase]
> > > > > autostash = true
> > > > >
> > > > > After downgrade to 2.33.0:
> > > > >
> > > > > % git pull
> > > > > Current branch local-fixes is up to date.
> > > >
> > > > This looks like the same bug discussed in:
> > > >
> > > > https://lore.kernel.org/git/CH2PR06MB650424B4205102AC6A48F489B1BD9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> > > >
> > > > There's a fix in that thread. It's currently in "next", but didn't quite
> > > > make the cutoff for the upcoming v2.34.0.
> > >
> > > For the record, the problem is still present in 2.34.1
> >
> > In the bug I linked (and what got fixed in 2.34.1), the issue is that
> > when the local branch is ahead of the remote, we don't say "up to date",
> > but complain about fast-forwards.
> >
> > It's hard to tell from the output above, but it looks like you have a
> > case where there are new commits both locally and on the remote? In
> > which case a rebase would work just fine.
> >
> > But why are we complaining about "not possible to fast-forward"? Testing
> > locally with something like:
> >
> > -- >8 --
> > git init repo
> > cd repo
> >
> > commit() {
> > echo $1 >$1
> > git add $1
> > git commit -m $1
> > }
> >
> > git checkout -b local
> > commit base
> > commit local
> >
> > git checkout -b remote HEAD^
> > commit remote
> >
> > git checkout local
> > git config pull.rebase true
> > git pull . remote
> > -- >8 --
> >
> > shows that we do rebase. If I set:
> >
> > git config pull.ff only
> >
> > then we start complaining. And that behavior did change in 2.33.1, but
> > I'm not sure it's wrong. We have two conflicting config options, and the
> > precedence for which one we pick switched.
> >
> > Do you have that option set in your config? Try:
> >
> > git config --show-origin --show-scope --get-regexp 'pull\..*'
> >
> >
> > -Peff
