After upgrade to 2.33.1, the behavior of `pull.ff=only` has changed in a way that breaks some workflows, notably the default used in VSCode.
Example (specific repo doesn't matter)
$ git clone git@github.com:kcarnold/util.git
...
$ cd util
$ echo "" > test
$ git add test
$ git commit -m "Test"
$ git -c pull.ff=only pull
fatal: Not possible to fast-forward, aborting.
$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
Previously this pull succeeded without error, which was as expected because no merge was necessary.
VS Code users have reported this problem because that editor has a "sync" option that seems to run something like `git pull && git push`.
On Tue, Oct 19, 2021 at 05:23:06PM +0000, Kenneth Arnold wrote:
After upgrade to 2.33.1, the behavior of `pull.ff=only` has changed in a way that breaks some workflows, notably the default used in VSCode.
Example (specific repo doesn't matter)
$ git clone git@github.com:kcarnold/util.git
...
$ cd util
$ echo "" > test
$ git add test
$ git commit -m "Test"
$ git -c pull.ff=only pull
fatal: Not possible to fast-forward, aborting.
$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
Previously this pull succeeded without error, which was as expected because no merge was necessary.
Thanks for reporting, this is an interesting case. I agree that it
probably ought to continue to be a noop. There is nothing to pull, and
so the question of ff-versus-merge should not even enter into it.
It bisects to Alex's (cc'd) 3d5fc24dae (pull: abort if --ff-only is
given and fast-forwarding is impossible, 2021-07-21). I'd guess it's
probably the hunk in pull.cc which checks "can_ff". The solution doesn't
seem entirely obvious to me though (at least in a way that retains what
that commit was trying to do).
-Peff