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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

>> +	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.

> 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.