Hi!
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.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amdmi3@amdmi3.ru ..: https://github.com/AMDmi3https://amdmi3.ru
From: Jeff King <hidden> Date: 2021-11-02 14:20:03
On Tue, Nov 02, 2021 at 04:58:43PM +0300, Dmitry Marakasov 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.
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.
For the record, the problem is still present in 2.34.1
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amdmi3@amdmi3.ru ..: https://github.com/AMDmi3https://amdmi3.ru
From: Jeff King <hidden> Date: 2021-11-26 21:46:54
On Fri, Nov 26, 2021 at 09:05:46PM +0300, Dmitry Marakasov wrote:
* Jeff King (peff@peff.net) wrote:
quoted
quoted
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.
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\..*'
+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.
-Peff
From: Jeff King <hidden> Date: 2021-11-26 21:47:46
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.
-Peff
On Fri, Nov 26, 2021 at 09:05:46PM +0300, Dmitry Marakasov wrote:
quoted
* Jeff King (peff@peff.net) wrote:
quoted
quoted
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.
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
On Fri, Nov 26, 2021 at 1:45 PM Jeff King [off-list ref] wrote:
On Fri, Nov 26, 2021 at 04:44:52PM -0500, Jeff King wrote:
quoted
+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).
quoted
On Fri, Nov 26, 2021 at 09:05:46PM +0300, Dmitry Marakasov wrote:
quoted
* Jeff King (peff@peff.net) wrote:
quoted
quoted
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.
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
From: Jeff King <hidden> Date: 2021-11-27 05:07:17
On Fri, Nov 26, 2021 at 02:43:44PM -0800, Elijah Newren wrote:
On Fri, Nov 26, 2021 at 1:45 PM Jeff King [off-list ref] wrote:
quoted
On Fri, Nov 26, 2021 at 04:44:52PM -0500, Jeff King wrote:
quoted
+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).
I thought that at first, too, but this case is a bit different:
quoted
quoted
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.
I think the key thing here is that (AFAICT) the behavior is unchanged
unless the user has set pull.ff=only explicitly.
-Peff
On Fri, Nov 26, 2021 at 9:05 PM Jeff King [off-list ref] wrote:
On Fri, Nov 26, 2021 at 02:43:44PM -0800, Elijah Newren wrote:
quoted
On Fri, Nov 26, 2021 at 1:45 PM Jeff King [off-list ref] wrote:
quoted
On Fri, Nov 26, 2021 at 04:44:52PM -0500, Jeff King wrote:
quoted
+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).
I thought that at first, too, but this case is a bit different:
quoted
quoted
quoted
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.
I think the key thing here is that (AFAICT) the behavior is unchanged
unless the user has set pull.ff=only explicitly.
Ah, I see there were two parts to their report, one of which is the
issue fixed in 2.34.1. I'll respond to his original email and ask if
he has pull.ff=only set and explain how that interacts with
pull.rebase.
Hi Dmitry,
On Tue, Nov 2, 2021 at 7:09 AM Dmitry Marakasov [off-list ref] wrote:
Hi!
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.
Was pull.ff also set? As per
https://lore.kernel.org/git/xmqqzgr3pso7.fsf@gitster.g/, --ff-only
overrides --rebase if both are given on the command line, and by the
same token, pull.ff=only will override a pull.rebase=true if both are
set.
Yes, I know it's weird that we have two separate potentially
contradictory settings. A single pull.mode would be better, but the
backward compatibility story to migrate is a long story. Prior to
v2.33.1/v2.34.0, we had a bunch of untested and mishandled
interactions.
% git pull --rebase
Successfully rebased and updated refs/heads/local-fixes.
Right, the command-line options take precedence over config, so if you
add pull.ff=only, the --rebase overrides.
% git pull
fatal: Not possible to fast-forward, aborting.
This was the bug fixed in v2.34.1; see ea1954af77 ("pull: should be
noop when already-up-to-date", 2021-11-17)
% 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.
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.
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/AMDmi3https://amdmi3.ru
On Thu, Dec 2, 2021 at 7:27 AM Dmitry Marakasov [off-list ref] wrote:
* Jeff King (peff@peff.net) wrote:
quoted
quoted
quoted
quoted
quoted
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.
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
ff is a tri-state -- false, true, or only. yes is equivalent to true
and means "allow but do not require fast forward updates".
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.
, 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.