From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 21 Sep 2007 19:32:25 GMT
Subject: Re: [PATCH 7/7] Implement git commit as a builtin command.
Message-ID: <7vwsujizli.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1190395088.31494.55.camel@hinata.boston.redhat.com>

Kristian Høgsberg <krh@redhat.com> 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.