Re: performance problem: "git commit filename"

From: Kristian Høgsberg <krh@redhat.com>
Date: Jan 14, 2008, 23:15 UTC
Message-ID: <1200352558.488.10.camel@gaara.boston.redhat.com>
In-Reply-To: <alpine.LFD.1.00.0801121735020.2806@woody.linux-foundation.org>

On Sat, 2008-01-12 at 17:46 -0800, Linus Torvalds wrote:

Show 18 quoted lines

> HOWEVER. When that logic was converted from that shell-script into a 
> builtin-commit.c, that conversion was not done correctly. The old "git 
> read-tree -i -m" was not translated as a "unpack_trees()" call, but as 
> this in prepare_index():
> 
> 	discard_cache()
> 	..
> 	tree = parse_tree_indirect(head_sha1);
> 	..
> 	read_tree(tree, 0, NULL)
> 
> which is very wrong, because it replaces the old index entirely, and 
> doesn't do that stat information merging.
> 
> As a result, the index that is created by read-tree is totally bogus in 
> the stat cache, and yes, everything will have to be re-computed.
> 
> Kristian?

Sorry for being late to the game, and yes, it's a bug I introduced with the rewrite. When doing the rewrite I was a bit puzzled by the

  git-read-tree --index-output="$TMP_INDEX" -i -m HEAD

part of the shell script. I carried a FIXME around in the patch for a while, as can be seen here:

  http://marc.info/?l=git&m=118478660425992&w=2

since I couldn't figure out what the difference in behavior was between just using read_tree(), which did exactly what I wanted and the more complicated unpack_tree(). I guess it fell through the cracks, especially since it never caused the test suite to fail :/

Kristian