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

Phillip Wood [off-list ref] writes:

As I said before[1] I think we should also be checking the reflog
dates so that we do not look at any local reflog entries that are
older than the most recent reflog entry for the remote tracking
branch. This protects against a background fetch when the remote has
been rewound and it would also reduce the number of calls to
in_merge_bases().

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.

Thanks.