From: Dmitry Marakasov <amdmi3@amdmi3.ru>
To: Jeff King <peff@peff.net>
Cc: Alex Henrie <alexhenrie24@gmail.com>,
Elijah Newren <newren@gmail.com>,
git@vger.kernel.org
Subject: Re: pull.rebase config option broken in 2.33.1
Date: Thu, 2 Dec 2021 18:26:05 +0300 [thread overview]
Message-ID: <Yajlf6e2aRIpTBqB@hades.panopticon> (raw)
In-Reply-To: <YaFViM1tTTAc48ZG@coredump.intra.peff.net>
* 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 = yes
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.
It looks like it could be fixed by either making `pull.rebase` on
repo level override `pull.ff` on global level, 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.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amdmi3@amdmi3.ru ..: https://github.com/AMDmi3 https://amdmi3.ru
next prev parent reply other threads:[~2021-12-02 15:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-02 13:58 pull.rebase config option broken in 2.33.1 Dmitry Marakasov
2021-11-02 14:20 ` Jeff King
2021-11-26 18:05 ` Dmitry Marakasov
2021-11-26 21:44 ` Jeff King
2021-11-26 21:45 ` Jeff King
2021-11-26 22:43 ` Elijah Newren
2021-11-27 5:05 ` Jeff King
2021-11-27 5:26 ` Elijah Newren
2021-12-02 15:26 ` Dmitry Marakasov [this message]
2021-12-02 16:54 ` Elijah Newren
2021-11-27 5:27 ` Elijah Newren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yajlf6e2aRIpTBqB@hades.panopticon \
--to=amdmi3@amdmi3.ru \
--cc=alexhenrie24@gmail.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).