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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 9, 2021, 17:50 UTC
Message-ID: <xmqqa6jif5pg.fsf@gitster.g>
In-Reply-To: <87wnmmkzaa.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 7 quoted lines

> 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.