Junio C Hamano <gitster@xxxxxxxxx> 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.
