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

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

Am I understanding this right?  You want the timestamps to be monotonically
increasing?  

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.

Is the +60 the most obvious choice?

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.

Can I get an example of how git can get confused?

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