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
> 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"
> 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 ;)
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.
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