On Tue, Jul 06, 2010 at 12:53:36PM -0400, tytso@xxxxxxx wrote: > We would be much better off if our tools enforced the fact that > committer times were always increasing. If from the beginning, we had > introduced checks so that "git commit" refused to create new commits > where the committer time was before its parent commit(s), and > git-receive-pack refused to accept packs that contained > non-monotonically increasing commits or commits that occurred in the > future according to its system clock, then these optimizations would > be completely valid. > > But we didn't, and we do have skew in some repositories. So the > question is what to do going forward? One solution might be to > enforce this moving forward, and to have varying levels of strictness > in enforcing this constraint. So for completely new repositories, Whatever we do with the optimization, I do agree with your suggestion at least for "git commit" to avoid making such commits. Rejecting them during fetchs and pushes would be a nice, too, but should probably just be a warning at first, in case you have to pull from somebody with an older git. You would also have to consider whether some small skew is acceptable during a pull. Something like a 5-second skew is not a big deal. If you had thousands of such skews in a row, yes, it would be bad, but that is not likely to happen (and I can't think of some way to maliciously create such a history that would not otherwise be unusable). > this becomes a non-brainer. For older repositories, Jeff's idea of > having a tunable parameter so that results are correct given a maximum > clock skew --- which can be determined --- will allow us to have > correctness _and_ performance. Yeah. I think the real question is what the default for that parameter should be: pessimistic but always correct, optimistic but possibly incorrect in the face of skew, or auto-tuned per-repository. -Peff -- 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