Re: performance problem: "git commit filename"

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 13, 2008, 05:38 UTC
Message-ID: <alpine.LNX.1.00.0801130028460.13593@iabervon.org>
In-Reply-To: <alpine.LFD.1.00.0801121949180.2806@woody.linux-foundation.org>

On Sat, 12 Jan 2008, Linus Torvalds wrote:

> It makes builtin-commit.c use the same logic that "git read-tree -i -m" 
> does (which is what the old shell script did), and it seems to pass the 
> test-suite, and it looks pretty obvious.

The only issue I know about with using unpack_trees in C as a replacement for read-tree in shell is that unpack_trees leaves "deletion" index entries in memory which are not written to disk, but may surprise some code (these are used to allow -u to remove the files from the working tree). So you may want to make sure that you don't get any weird results out of a commit of particular files that involves not committing some newly-added files:

$ git add new-file $ (edit old-file) $ git commit old-file

This may cause the unpack_trees to leave a misleading entry for new-file that the code doesn't expect. I've got a patch to make it saner as part of my builtin-checkout series, but I can't say for sure that that change won't either confuse something else or have performance problems without a bunch of analysis I haven't done recently.

	-Daniel
*This .sig left intentionally blank*