Linus Torvalds [off-list ref] writes:
On Thu, 9 Aug 2007, Junio C Hamano wrote:
quoted
While I do not think the previous one was hacky at all, this one
IS a hack, not meant for inclusion.
...
Sadly, that removal is required for some of the other cases, so it's not
like we can remove the remove. But we could *possibly* make things
ridiculously much faster by making the remove a lazy thing, and if the
next index operation just adds it back in, we wouldn't move things around.
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 ;-).
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