On Tue, Jul 6, 2010 at 10:03 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > tytso@xxxxxxx wrote: >> On Mon, Jul 05, 2010 at 02:52:38PM -0400, jeffpc@xxxxxxxxxxxxxx wrote: > >>> if I commit, and immediately after push 10 patches, wouldn't the HEAD end up >>> with a commit that's ~10 minutes in the future? > > I don’t think git has ever required commit dates to be _strictly_ > monotonic. > > At one point rev-list did require monotonic --- i.e., the committer > date of each commit had to be equal to or later than that of each of > its parents) with no clock skew but that was considered a bug and > fixed by v1.5.5-rc1~16 (Make revision limiting more robust against > occasional bad commit dates, 2008-03-17) > This might be a stupid question, but I'm not entirely clear on why it's not a strict requirement; surely it would be easy to ensure that the commit-time is at least as big as the parents when generating the commit...? Is it to avoid the case where a user commits with the clock set to some point (potentially far) in the future, so all subsequent commits would have the same, artificially high commit time? Or is there some other reason I can't think of? -- Erik "kusma" Faye-Lund -- 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