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 -- 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