Re: performance problem: "git commit filename"

On Sat, 12 Jan 2008, Linus Torvalds wrote:

It's new, and yes, it seems to be due to the new builtin-commit.c.

I think I know what is going on.

In the old git-commit.sh, this case used to be handled with

	TMP_INDEX="$GIT_DIR/tmp-index$$"

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

which is a one-way merge of the *old* index and HEAD, taking the index information from the old index, but the actual file information from HEAD (to then later be updated by the named files).

This logic is implemented by builtin-read-tree.c with

	struct unpack_trees_options opts;
	..
	opts.fn = oneway_merge;
	..
	unpack_trees(nr_trees, t, &opts);

where all the magic is done by that "oneway_merge()" function being called for each entry by unpack_trees(). This does everything right, and the result is that any index entry that was up-to-date in the old index and unchanged in the base tree will be up-to-date in the new index too

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?

			Linus