Re: git and larger trees, not so fast?

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Aug 10, 2007, 00:57 UTC
Message-ID: <alpine.LFD.0.999.0708091754150.25146@woody.linux-foundation.org>
In-Reply-To: <7vhcn8w6sw.fsf@assigned-by-dhcp.cox.net>

On Thu, 9 Aug 2007, Junio C Hamano wrote:

Show 5 quoted lines

> 
> Heh, that makes the two of us.  I have been wanting to revamp or
> kill off unpack-trees for quite some time, and after all the
> patch you are responding to might be a small first step in the
> right direction ;-).

Well, the patch you sent out was not only hacky, it was kind of pointless.

Without the "-m" handling, it means that most users of git-read-tree won't ever see the improvement. The merge with the old index is absolutely critical for things like switching branches, for example. And I think you probably screwed up performance with your change to git-commit to simply not use it, because now the resulting index will be totally stale, and while the *commit* may be fast as a result, the subsequent operations might be horrible.

(I didn't test it, though, maybe I missed something).

So I do think that things like "git checkout <otherbranch>" need to have a fully working (and fast) unpack-trees, and your hack doesn't really help except for a pretty uninteresting special case.

		Linus