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 git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
