Jeff King <peff@xxxxxxxx> 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.