On Sat, 12 Jan 2008, Linus Torvalds wrote: > > I thought we had fixed this long long ago, but if we did, it has > re-surfaced. 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 - 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
