Re: jk/tag-contains (Re: What's cooking in git.git (Jul 2010, #05; Wed, 28))

From: Jeff King <peff@peff.net>
Date: Jul 31, 2010, 12:33 UTC
Message-ID: <20100731123328.GA5273@coredump.intra.peff.net>
In-Reply-To: <20100731060703.GA21207@burratino>

On Sat, Jul 31, 2010 at 01:07:03AM -0500, Jonathan Nieder wrote:

Show 6 quoted lines

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