From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 4A0821F85E; Thu, 12 Jul 2018 22:29:08 +0000 (UTC) Date: Thu, 12 Jul 2018 22:29:08 +0000 From: Eric Wong To: Konstantin Ryabitsev Cc: "Eric W. Biederman" , meta@public-inbox.org Subject: Re: Warnings from git fsck after lkml import Message-ID: <20180712222907.7illolxejpwpuw2e@dcvr.yhbt.net> References: <87a7r6z1cy.fsf@xmission.com> <20180705231346.GA6524@dcvr> <20180712183151.GA9085@chatter> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180712183151.GA9085@chatter> List-Id: Konstantin Ryabitsev wrote: > On Thu, Jul 05, 2018 at 11:13:46PM +0000, Eric Wong wrote: > > "Eric W. Biederman" wrote: > > > It looks like public-inbox has some challenges when importing some > > > questionable emails. The import of lkml has resulted in several commits > > > with bad dates that git fsck complains about. I have previously > > > reported this to Konstantin Ryabitsev who maintains kernel.org but since > > > I have not seen any discussion of this I thought I should report it > > > directly here as well. > > > > Thanks for bringing this up publically. > > > > Yes, I early during v2 development I noticed old mails had some > > -1400 timezone values (but the furthest is -1200). I opted to > > attempt to preserve the wonky timezones since fast-import > > happily accepts -1400 and I didn't anticipate problems... > > So, I can fix those in the archives, but this obviously requires rebasing > the whole repo, and I'm not sure what kind of impact that would have. I'm > assuming it's not sufficient to just fix the git repo, as all commit IDs > after the modified commit are going to be different -- so additional changes > to sqlite and xapian dbs would be required? Yes, I think the internal "purge" and normal add operation should take care of Xapian/SQLite changes. NNTP serial numbers will change and readers will redownload a few messages, though. Personally, I wouldn't bother since it'd be disruptive to existing clones and I don't consider them to be big enough problems worth breaking changes if git itself doesn't complain by default.