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

[tytso@mit.edu]

On Tue, Jul 06, 2010 at 05:02:51PM +0200, Erik Faye-Lund wrote:
> But I can imagine it becoming a big deal when the skew is high. The
> again, perhaps this should constitute a "bad commit" and commit should
> error out if a parent commit was more than some number of minutes
> newer than the current time (or whatever)? That way, skewed commits
> would be caught early if a developer is working with other people, and
> a lot of the traversal could perhaps be faster (or more robust). If
> the developer with the skewed clock doesn't work with anyone, skew
> isn't really a problem, but perhaps he'd have to do some
> branch-filtering to un-skew commits when starting to work with others.
> And only if the skew is really high... like, multiple days... Which
> can't really be THAT common?

Guilt uses the modtime of the patch in a patch series for the
committer time and the author time.  The reasoning behind it doing
this is so that you can do "git pop -a" followed by "git push -a" and
if the patch files haven't changed, the commit id's don't change
either.

But if you change a commit in the middle of the series, you can end up
with clock skews that could be several days or weeks.  Becuase of my
ext4 workflow, the Linux kernel has a maximum skew of 100 days.  Mea
culpa; I stopped doing this as soon as I was told that git was
depending on committer time being roughly increasing, and so I at
least haven't introduced any such time skews since v2.6.34.  And part
of my making up for this has been to submit a patch to guilt to
prevent this from happening again in the future, by fixing up guilt so
that it won't request "git commit" to create timestamps that show very
wild clock skews within a single linear branch.

We could still get potentially screwed though.  Every so often I will
see someone sending e-mail from a client host whose time is years if
not decades in the past or in the future.  If they were to do a "git
commit", and then push that commit to a public repository, we could
easily introduce a large clock skew into a git repo.  Has that ever
happened to date?  Not to my knowledge.  Could it happen?  Very
clearly, yes.  Should we try to put in some safety checks to prevent
it, or at least issue warnings?  Maybe.

						- Ted