Re: [PATCH v4 1/3] push: add reflog check for "--force-if-includes"

Junio C Hamano [off-list ref] writes:

Meaning we first check the timestamp of the topmost reflog entry of
remote-tracking branch (i.e. the time *we* acquired the tip commit
that we are about to lose), and leverage on the fact that no local
commit older than that timestamp can possibly be written with the
knowledge of that remote work?  Assuming that local timestamp is
monotonically increasing, it is a quite valid optimization (and the
clock skew we often talk about in the context of revision traversal
are often discrepancy between matchines).

Having said that.

The new generation number based on (adjusted) timestamp is being
worked in, and that work is supposed to bring such an optimization
to us automatically (at least on the reachability's side, i.e. logic
that uses get_merge_bases()), I think, so we probably do *not* want
to add such a heuristics specifically for this codepath.

Eh, I spoke too soon before I thought it through.  I do not think we
will gain "assume that any commit whose timestamp is older than this
externally given one will never reach the other commit" even with
the reachability index based on (adjusted) timestamp.  At least,
stopping the traversal of reflog entries of the local side at the
timestamp of the topmost reflog entry of remote-tracking branch in
question would be an easy, worthwhile and sensible optimization.

Thanks.