Re: pull.rebase config option broken in 2.33.1
On Thu, Dec 2, 2021 at 7:27 AM Dmitry Marakasov <amdmi3@amdmi3.ru> wrote:
Show 95 quoted lines
>
> * Jeff King (peff@peff.net) 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@CH2PR06MB6504.namprd06.prod.outlook.com/
> > > > >
> > > > > 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\..*'
>
> Yes, I have both `pull.ff=only` and `pull.rebase` set, but these
> come from different configs:
>
> % git config --show-origin --show-scope --get-regexp 'pull\..*'
> global file:/home/marakasov/.gitconfig pull.ff only
> local file:.git/config pull.rebase true
>
> IMO the setup is perfectly legal, as I want to disable merge on pull
> in any case, and I also want rebase for a specific repo. So the
> problem is then in how these options override (not) each other.
>
> The following change in repo's config fixes this issue for me:
>
> [pull]
> + ff = yesff is a tri-state -- false, true, or only. yes is equivalent to true and means "allow but do not require fast forward updates".
Show 7 quoted lines
> rebase = true
>
> But IMO it still needs to be fixed in git, as the cause of this
> problem is quite unobvious and it does not feel right that local
> repo config should be aware of global config and include explicit
> overrides not really realated to the local repo config, for the
> latter to work as expected.
If you had pull.ff=only and pull.rebase=true in your local config, it would also error out. Thus, it makes sense that having pull.ff=only in global config and pull.rebase=true in local config should error out. The scope at which you get the variables doesn't matter, other than that if you set the same variable in both, clearly local should override global.
> It looks like it could be fixed by either making `pull.rebase` on
> repo level override `pull.ff` on global level
Scopes can only matter when the same config option is set in both local and global config. By the time we get to the program logic trying to interpret options, there is no notion of which scope the config came from.
Show 5 quoted lines
> , or reorganizing the
> options so no override is required, for example by introducing e.g.
> `pull.merge=off` instead of `pull.ff=only`. This way having both
> `pull.merge=off` and `pull.rebase=true` will not contradict each
> other and will not require any cross-variable override logic.
Your suggestion to add a third variable to the mix would increase the worries of cross-variable override logic, not decrease it. For example, what if pull.merge=true and pull.rebase=true? It'd be better if we could go back in time and have a single pull.mode instead of having two options; adding a third would be going in the wrong direction.
Anyway, both merges and rebases are capable of fast-forward updates. pull.ff=only corresponds to the --ff-only command line option, documented in git-pull as "Only update to the new history if there is no divergent local history." Thus, that setting is incompatible with reconciling divergent changes, which means that neither merging nor rebasing should proceed.
If you usually want to avoid merges & rebases, but in one repo you want to have rebases, then in addition to setting pull.rebase=true you'll also need to override pull.ff by setting it to true (or equivalently to 'yes' as you did) in your local config as well.
Dmitry Marakasov
