On Jul 4, 2010, at 10:59 PM, jeffpc@xxxxxxxxxxxxxx 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html