Junio C Hamano <gits...@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?
