Re: [PATCH 2/3] merge-base: return fork-point outside reflog

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

Junio C Hamano <gitster@pobox.com> writes:

> ...  I agree that there is a value in what your patch 2/3
> wants to do when the current one that is more strict would say
> "there is no known fork-point"---we would gain a way to say "... but
> this is the best guess based on available data that may be better
> than getting no answer." which we lack.
>
> Having said all that, I do not agree with your last sentence in the
> paragraph I quoted above.  It is a mere implementation detail to
> consult the reflog to find out the set of "historical tips of the
> Branch"; the current tip by definition is among the commits in that
> set, even when the reflog of Branch is missing.  What 4f21454b55 did
> was a reasonable "fix" that is still in line with the definition of
> "--fork-point" from that point of view.
>
> Whether we add a "looser" version of "--fork-point" to the system or
> not, the more strict version should still use the current tip as one
> of the historical tips (i.e. those that we would take from the
> reflog if the reflog were not empty) in the more "strict" mode.  The
> looser version may also want to do so as well.

So, should I mark this in What's cooking report as "expecting a
reroll", anticipating that a new option would be added to trigger
the new & looser behaviour?