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) > diff --git a/guilt b/guilt > index b6e2a6c..edcfb34 100755 > --- a/guilt > +++ b/guilt > @@ -535,6 +535,17 @@ commit() > export GIT_AUTHOR_EMAIL="`echo $author_str | sed -e 's/[^<]*//'`" > fi > > + ct=$(git log -1 --pretty=%ct) > + if [ $ct -gt $(stat -c %Y "$p") ]; then > + echo "Adjusting mod time of" $(basename "$p") > + ct=$(expr $ct + 60) > + if [ $ct -gt $(date +%s) ]; then > + touch "$p" > + else > + touch -d @$(expr $ct + 60) "$p" So I would suggest echo "Adjusting mod time of $(basename "$p")" touch -d "$ct" "$p" If the parent commit time happens to be in the future, well, at least we’re not making it worse. By the way, I think your idea to have commit warn about nonmonotonic commit dates is a good one. We should also decide on a rule, hopefully one the kernel repo obeys (30 days max skew? *crosses fingers*) and make git fsck warn loudly about violations. -- 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