From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ted Ts'o Subject: Re: Git commit generation numbers Date: Thu, 14 Jul 2011 16:08:17 -0400 Message-ID: <20110714200817.GF8453@thunk.org> References: <20110714183710.GA26820@sigill.intra.peff.net> <20110714194638.GE8453@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jeff King , Git Mailing List , Junio C Hamano To: Linus Torvalds X-From: git-owner@vger.kernel.org Thu Jul 14 22:08:27 2011 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QhSCw-0003xV-To for gcvg-git-2@lo.gmane.org; Thu, 14 Jul 2011 22:08:27 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753503Ab1GNUIW (ORCPT ); Thu, 14 Jul 2011 16:08:22 -0400 Received: from li9-11.members.linode.com ([67.18.176.11]:33106 "EHLO test.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753065Ab1GNUIV (ORCPT ); Thu, 14 Jul 2011 16:08:21 -0400 Received: from root (helo=tytso-glaptop) by test.thunk.org with local-esmtp (Exim 4.69) (envelope-from ) id 1QhSCo-0000Ee-7u; Thu, 14 Jul 2011 20:08:18 +0000 Received: from tytso by tytso-glaptop with local (Exim 4.71) (envelope-from ) id 1QhSCn-0007YQ-EB; Thu, 14 Jul 2011 16:08:17 -0400 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on test.thunk.org); SAEximRunCond expanded to false Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Thu, Jul 14, 2011 at 12:51:39PM -0700, Linus Torvalds wrote: > > So it sounds like it would work - and it would probably be a simple > matter of just incrementing the pack version number if you just say > "cannot access the pack with old versions" - but I think it's a really > fragile approach. So if we ever change the pack format again, it's something to think about adding, but probably not worth it on its own... What if we simply have a cache file per pack, which again is generated when the pack is first received or generated, but is otherwise not dynamic? It's an extra file which is icky, but it would keep things simpler. - Ted