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@xxxxxxxxxx: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
