Re: [PATCH] guilt: Make sure the commit time is increasing

On Jul 4, 2010, at 10:59 PM, jeffpc@josefsipek.net wrote:

Yup, that's correct. In more modern versions of git most (all?) of the places that depend on the committer time of the child commit to be greater than the committer time of its parents have been relaxed to accept up to a day's worth of clock skew, but in the interests of "be conservative in what you send", strictly increasing seemed like the best thing to do.

It's somewhat arbitrary. I figured a minute increase between commits was more aesthetically pleasing than a second, 5 minutes, or an hour, which were some other deltas that previous versions of my patch used while I was experimenting.

This first one is explicitly my/guilt's fault (and it's when I learned that I was causing problems by how I was using guilt in the ext4 tree):

http://kerneltrap.org/mailarchive/git/2010/4/22/28928/thread

In this thread we see how the clock skew gets in the way of an optimization that speeds up "git tag --contains" by over two orders of magnitude, but it gets screwed over by extreme clock skew. I suggested in that thread that if git is going to depend on it, then maybe "git commit" should either warn or error out if the git committer timestamp goes backwards --- and that's when I decided maybe I should offer up a patch to guilt to fix this, either before or instead of fixing up "git commit" to throw a warning/error:

http://www.spinics.net/lists/git/msg134307.html

Other threads:

http://kerneltrap.org/mailarchive/git/2010/4/8/27731/thread http://www.kerneltrap.com/mailarchive/git/2007/5/24/247375

-- Ted