From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: [1.8.0] reorganize the mess that the source tree has become Date: Mon, 31 Jan 2011 20:57:36 -0500 Message-ID: <20110201015736.GC2722@sigill.intra.peff.net> References: <7vzkqh8vqw.fsf@alter.siamese.dyndns.org> <7vwrll57ha.fsf@alter.siamese.dyndns.org> <20110131210045.GB14419@sigill.intra.peff.net> <20110131231210.GD14419@sigill.intra.peff.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Nicolas Pitre , Junio C Hamano , git@vger.kernel.org To: Sverre Rabbelier X-From: git-owner@vger.kernel.org Tue Feb 01 02:57:45 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 1Pk5V2-0007RG-7X for gcvg-git-2@lo.gmane.org; Tue, 01 Feb 2011 02:57:44 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754283Ab1BAB5j (ORCPT ); Mon, 31 Jan 2011 20:57:39 -0500 Received: from xen6.gtisc.gatech.edu ([143.215.130.70]:49772 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754062Ab1BAB5i (ORCPT ); Mon, 31 Jan 2011 20:57:38 -0500 Received: (qmail 15849 invoked by uid 111); 1 Feb 2011 01:57:38 -0000 Received: from 99-108-226-0.lightspeed.iplsin.sbcglobal.net (HELO sigill.intra.peff.net) (99.108.226.0) (smtp-auth username relayok, mechanism cram-md5) by peff.net (qpsmtpd/0.40) with ESMTPA; Tue, 01 Feb 2011 01:57:38 +0000 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Mon, 31 Jan 2011 20:57:36 -0500 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Tue, Feb 01, 2011 at 02:00:05AM +0100, Sverre Rabbelier wrote: > Heya, > > On Tue, Feb 1, 2011 at 00:12, Jeff King wrote: > > [1] I'd be interested to see how much we can get around that slowness > > using a notes-cache. > > Do you mean something like a refs/notes/renames namespace in which we > stick notes on commits indicating that a rename indicated at that > commit, with an option of the user, after-the-fact, adding this > information manually? Yes, without the "option of the user..." bit. Basically just cache the list of renames for a given commit against its parent (which should be immutable[1]), under the assumption that it is cheaper to look up the note than it is to calculate the renames. But I would make it purely a cache, not some place for users to stick their own generated rename information (if people really want to do that, I would much rather see it go into the commit itself as a pseudo-header). -Peff [1] It's technically not immutable if you limit the pathspec, or if you have non-standard rename options. But you could define some "canonical" rename set, like all of the pairs found doing rename detection with -M90 when considering the whole set of removed files as sources and added files as destinations. That would cover the common case of people running "git log", and then more specialized detection would not use the cache.