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

[Jonathan Nieder <jrnieder@gmail.com>]

tytso@mit.edu wrote:
> On Mon, Jul 05, 2010 at 02:52:38PM -0400, jeffpc@josefsipek.net 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.