Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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. -- 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
