Theodore Tso wrote: > You're right that it's been a while since git has run into problems with > mild forms of clock skew (even Debian Stable is shipping v1.5.6) but > I think it's better to times in the future if we can at all help it, and it's not > like we're talking about a lot of extra complexity to guilt to test for this. Sorry, I’m a little lost. There are five phenomena one could forbid: 1. Commits with timestamp equal to or before a parent 2. Commits with timestamp before a parent 3. Commits with timestamp unreasonably long before a parent 4. Commits with timestamp unreasonably long before an ancestor 5. Commits with timestamp in the future Git has always been able to cope with #5 (timestamps in the future). I see no reason to avoid it, except that it is hard to assign a timestamp for commits on top of that one. Git’s problem today is #4 (long-term slop). Maybe as Jeff suggested "unreasonably long" should defined per repository. Or we could measure the kernel’s maximum (something like 120 days?) and make that a hard limit. Do #3 a few times, and you get #4. So ‘commit’ should warn about it (where ‘unreasonably long’ could be as short as 0 or 1 days). #2 (nonmonotonic commits) was broken in ancient git; I think it’s too rigid of a rule to worry about it on that account. But a variant of the rationale for avoiding #3 applies to it. I have never heard of any version of Git copying poorly with #1 (commits with the same timestamp). Avoiding it artificially leads inevitably to timestamps in the future when you somehow try to assign 100 timestamps for the series you have rebased on top of a patch committed a few seconds ago. Incrementing the timestamp to ensure strictly monotonic commits seems like a recipe for trouble to me. For guilt, I think the best thing to do would to save a Date: line for the author date with the From: and Subject: and then touch patches with the _current_ date when appropriate to avoid skew. HTH, Jonathan -- 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