Phillip Wood <phillip.wood123@xxxxxxxxx> 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.
