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

[Junio C Hamano <gitster@pobox.com>]

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.