On Sat, Jul 31, 2010 at 01:07:03AM -0500, Jonathan Nieder wrote: > > The third one is where we start defaulting things to "assume no more > > than 1 day of clock skew by default", which can cause incorrect answers > > in the face of skew. > > I think the default should be something that (just barely) works > correctly for linux-2.6.git. I am tempted by that (and it is why I made the fourth patch to actually calculate the worst skew). But my concern is that there are projects with even worse skew. Maybe that is unfounded. > > The fourth is just an illustrative patch for per-repo skew detection. > > I have been hoping for a chance to look these over, time hasn’t come my > way yet. It just a git-skew program to calculate the skew, but doesn't do anything fancy like detect-on-gc. However, it would be nice to have somebody sanity check the algorithm. Looking at it again, I think it might actually miss some skew if the skewed commit can be reached in multiple ways. > Additional things to do (this is mostly a note to myself): > > - refuse to commit with a timestamp long before any parent Agreed. > - refuse to make a commit that would make the total slop too high? That would be expensive to commit, and if we bound each individual commit to parent relationship as you mention above, I don't think it should be necessary. > - check slop and warn about it in fsck (maybe your patch does this > already) No, it doesn't, but it is something we should probably do. > - document the maximum-total-slop and maximum-single-commit-slop > rules! Definitely. -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