Re: "git reflog expire" blindly trusting timestamps in reflogs

Ævar Arnfjörð Bjarmason [off-list ref] writes:

I.e. shouldn't reflog expiry at least have the invariant that nothing
should expire in a given file if the tip commit is old enough to be
expired, *AND* the mtime of the file is more recent than the expiry
epoch, because such a scenario points to either git's own test suite
(and we should just fake up the time there), or that we're about to
corrupt some user's repository because they're either doing similar
import work, or their clock was screwy?

A reflog whose entries (and possibly the containing file) have
inconsistent timestamps might need some care when pruning.  If the
time @{1} has is older than @{2}, there may be something fishy going
on.  Expiring @{1}, keep @{2}, and expire @{3} in such a case where
@{2} is exceptionally new but all others are older than expiry limit
is one possibility, but "entries out of order detected---do you want
to keep the one that is sandwiched between much older ones [y/N]?"
might be worth asking.  In any case, a reflog with such unordered
entries may not answer time-based @{1.week.ago} question correctly.

I do not think, at least by default, we should care about file's
mtime to the same degree, because it can easily be modified by
accident and because the timestamps on entries and mtime can come
from different time sources, and the local clock may be faster than
the fileserver's clock, resulting in the tip entry having a more
recent timestamp than the file's mtime.