Re: git and larger trees, not so fast?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Thu, 9 Aug 2007, Junio C Hamano wrote:
> 
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux