From: Kristian Høgsberg <krh@redhat.com>
Date: Mon, 19 Nov 2007 16:47:35 GMT
Subject: Re: [PATCH] builtin-commit: fix partial-commit support
Message-ID: <1195490855.16221.2.camel@hinata.boston.redhat.com>
In-Reply-To: <1195381287-26823-4-git-send-email-gitster@pobox.com>

On Sun, 2007-11-18 at 02:21 -0800, Junio C Hamano wrote:
> When making a partial-commit, we need to prepare two index
> files, one to be used to write out the tree to be committed
> (temporary index) and the other to be used as the index file
> after the commit is made.
> 
> The temporary index needs to be initialized to HEAD and then all
> the named paths on the command line need to be staged on top of
> the index.  For this, running add_files_to_cache() that compares
> what is in the index and the paths given from the command line
> is not enough -- the comparison will miss the paths that the
> user previously ran "git add" to the index since the HEAD
> because the index reset to the HEAD would not know about them.
> The index file needs to get the same modification done when
> preparing the temporary index as described above.
> 
> This implementation mimics the behaviour of the scripted
> version of git-commit.  It first runs overlay_tree_on_cache(),
> which was stolen from ls-files with the earlier change, to get
> the list of paths that the user can potentially mean, and then
> uses pathspec_match() to find which ones the user meant.  This
> list of paths is used to update both the temporary and the real
> index file.

Oh boy, this turns out to be much more involved than what I thought.
Thanks for fixing up this part of builtin-commit.

> Additionally:
> 
>  - remove the temporary index file .git/next-index-* after
>    commit is done or aborted.

Hmm, I see the left-over next-index-* files too, but I though the lock
file would be cleaned up automatically by the atexit handler?

cheers,
Kristian