Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261208AbVDSXqH (ORCPT ); Tue, 19 Apr 2005 19:46:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261217AbVDSXqH (ORCPT ); Tue, 19 Apr 2005 19:46:07 -0400 Received: from nacho.zianet.com ([216.234.192.105]:34064 "HELO nacho.zianet.com") by vger.kernel.org with SMTP id S261208AbVDSXp6 (ORCPT ); Tue, 19 Apr 2005 19:45:58 -0400 From: Steven Cole To: Linus Torvalds Subject: Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2 Date: Tue, 19 Apr 2005 17:41:57 -0600 User-Agent: KMail/1.6.1 Cc: Greg KH , Greg KH , Git Mailing List , linux-kernel@vger.kernel.org, sensors@stimpy.netroedge.com References: <20050419043938.GA23724@kroah.com> <200504191704.48976.elenstev@mesatop.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200504191741.57626.elenstev@mesatop.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1957 Lines: 50 On Tuesday 19 April 2005 05:38 pm, Linus Torvalds wrote: > > On Tue, 19 Apr 2005, Steven Cole wrote: > > > > I wasn't complaining about the 4 minutes, just the lack of feedback > > during the majority of that time. And most of it was after the last > > patching file message. > > That should be exactly the thing that the new "read-tree -m" fixes. > > Before, when you read in a new tree (which is what you do when you update > to somebody elses version), git would throw all the cached information > away, and so you'd end up doing a "checkout-cache -f -a" that re-wrote > every single checked-out file, followed by "update-cache --refresh" that > then re-created the cache for every single file. > > With the new read-tree, the same sequence (assuming you have the "-m" > flag to tell read-tree to merge the cache information) will now only write > out and re-check the files that actually changed due to the update or > merge. > > So that last phase should go from minutes to seconds - instead of checking > 17,000+ files, you'd end up checking maybe a few hundred for most "normal" > updates. > > For example, updating all the way from the git root (ie plain 2.6.12-rc2) > to the current head, only 577 files have changed, and the rest (16,740) > should never be touched at all. > > You can see why doing just the 577 instead of the full 17,317 might speed > things up a bit ;) > > Linus Cool. Petr, I hope this works like this with your tools tomorrow. > > PS. Of course, right now it probably does make sense to waste some time > occasionally, and run "fsck-cache $(cat .git/HEAD)" every once in a while. > Just in case.. > > Sounds like a good thing to schedule for $WEEHOUR. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/