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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 2, 2010, 04:04 UTC
Message-ID: <7vocdlpsmw.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20100731123328.GA5273@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 17 quoted lines

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

Sorry, but I am right in the middle of phisically moving, so my weekend and evening git time has been nil recently.

Show 11 quoted lines

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

You need to be careful here, though. What if you pulled from somebody whose clock is set grossly in the future?

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

I wonder if we can make fsck to notice a commit with a wrong timestamp (i.e. older than some of its parents) and make a note of it (hopefully they are miniscule minority)---then during the revision traversal when we hit such a commit, we perhaps ignore its timestamp (pretending as if its timestamp is one of its children or parent---I haven't thought about the details, but the note fsck leaves can record what adjusted timestamp should be used) to fix the issue?