Kristian Høgsberg <krh@xxxxxxxxxx> writes:
>> > +
>> > + /* update the user index file */
>> > + add_files_to_cache(fd, files, prefix);
>> > +
>> > + if (!initial_commit) {
>> > + tree = parse_tree_indirect(head_sha1);
>> > + if (!tree)
>> > + die("failed to unpack HEAD tree object");
>> > + if (read_tree(tree, 0, NULL))
>> > + die("failed to read HEAD tree object");
>> > + }
>>
>> Huh? Doesn't this read_tree() defeat the add_files_to_cache()
>> you did earlier?
>
> This is the case where we add the files on the command line
> to .git/index, but commit from a clean index file corresponding to HEAD
> with the files from the command line added (partial commit?). The first
> add_files_to_cache() updates .git/index, then we do read_tree() to build
> a tmp index from HEAD and then we add the files again. The tmp index is
> written to a tmp index file.
Still, if you are doing read_tree() that reads into the same
in-core cache you have just prepared in the add_fiels_to_cache()
above, potentially overwriting whatever you did, doesn't it?
That was what I was puzzled about...
> ... As for just using an in-memory
> index, I wanted to do it that way originally, but you have to write it
> to disk after all for the pre-commit hook.
Ah, I completely forgot about the hook. Ok, scratch the idea of
not using a temporary index file. The is not much potential for
performance gain anyway.
-
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
