Re: "Not possible to fast-forward" when pull.ff=only and new commits on remote

From: Jeff King <peff@peff.net>
Date: Oct 19, 2021, 21:22 UTC
Message-ID: <YW83JG9t2JaX92xV@coredump.intra.peff.net>
In-Reply-To: <CH2PR06MB650424B4205102AC6A48F489B1BD9@CH2PR06MB6504.namprd06.prod.outlook.com>

On Tue, Oct 19, 2021 at 05:23:06PM +0000, Kenneth Arnold wrote:

Show 20 quoted lines

> 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