Re: [PATCH 0/4] Make unpack_trees() do separate source and destination indexes

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 7, 2008, 05:45 UTC
Message-ID: <7vwsof3x5n.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <cover.1204856187.git.torvalds@linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

> Ok, this goes on top of the five-commit series yesterday.  The first two
> patches are pure fixes and cleanups, the third one does a fairly
> mechanical thing to get rid of implied usage of "the_index", and the
> last one actually splits up the source and destination index handling.

What I have been wondering about this series was if we can re-enable cache-tree for more of the unpack_trees() users.

Currently, all unpack_trees() users, other than a single-tree read-tree, invalidates the whole cache-tree information, as Daniel's "pop one, decide what to put back, all in the original index" had too many manual index manipulations and sprinkling cache_tree_invalidate() call everywhere was too much cluttering of already hard-to-follow codepath.

I'd want to see at least two-way read-tree preserve as much cache-tree information as possible. People often work on one branch to completion (i.e. make a commit, which involves a write-tree, which leaves a fully valid cache-tree in the index), switch branches (i.e. two-way read-tree, which unfortunately decimates cache-tree in the current implementation) to commit a small fix. If major parts of the cache-tree were left intact during branch switching, these unchanged subdirectories do not have to be rehashed in write-tree when making this final commit.