Junio C Hamano wrote:
You need to be careful here, though. What if you pulled from somebody
whose clock is set grossly in the future?
We could check for that and give relevant advice:
fatal: committer date <date> precedes parent date <date>
hint: It looks like you are trying to commit on top of a commit
hint: from 5 years into the future.
hint: Use "git rebase -f" to rewrite the commit with a more
hint: sensible date, and please, fix your clocks!
I wonder if we can make fsck to notice a commit with a wrong timestamp
(i.e. older than some of its parents) and make a note of it (hopefully
they are miniscule minority)---then during the revision traversal when we
hit such a commit, we perhaps ignore its timestamp (pretending as if its
timestamp is one of its children or parent---I haven't thought about the
details, but the note fsck leaves can record what adjusted timestamp
should be used) to fix the issue?
Thanks --- at first glance, this idea would seem to allow much faster
revision limiting.