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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 20, 2021, 19:19 UTC
Message-ID: <xmqqa6j3pkqw.fsf@gitster.g>
In-Reply-To: <YXBNY7/mWyxvAo/r@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

>> +	ours = lookup_commit_reference(the_repository, orig_head);
>
> I think orig_head can be the null oid if we're on an unborn HEAD. I
> guess you'd want to return "1" in that case (but I could be wrong; it
> looks like get_can_ff() assumes it's valid, so perhaps that case is
> handled earlier).

It is a good point; the main codeflow already special cases the unborn HEAD to delegate to pull_into_void() before it gets to the point to call get_can_ff().

> I'd expect that merge_heads can never be empty here, or we'd bail
> earlier in the command

Yes, that happens even before that "are we unborn" check.

Show 9 quoted lines

> Running a sequence of traversals like this can be slow, because we may
> walk over the same history again and again. But I think in the usual
> non-octopus cases we'd only have one entry, so we'd only be adding a
> single extra merge-base traversal in most cases.
>
> It does feel like this could be combined with get_can_ff() somehow so
> that we're not adding even that single traversal. But I expect that may
> be hard to do because of the multiple heads (e.g., we cannot use the
> usual ahead/behind code).

I'd leave such an optimization as a separate topic. This was meant to be a regression fix.