Junio C Hamano <junkio@xxxxxxx> writes: > Well, I was blind ;-). As long as the whole-file SHA1 matches, > read_cache() does not care if we have extra data after the > series of active_nr cache entry data in the index file. > > I'm working on a patch now. So I did. There is one bad thing; so far "write-tree" was a read-only consumer of the index file, but now it primes the cache-tree structure and needs to update the index. But that is minor. While I was at it, I made this "stuffing extra cruft in the index" slightly more generic than I needed it for this particular application. What I see this _might_ be useful for are: - We would want to store which commit of a subproject a particular subdirectory came from. This was one missing piece from the "bind commit" proposal that wasn't implemented in the jc/bind branch. - We might want to record "at this path there is a directory, albeit empty"; this cannot be expressed with an usual index entry. We might be able to use cache-tree for that, but I think this is something different at the logical level. While cache-tree is to be fully populated (by write-tree and perhaps read-tree later) and invalidated partially when update-index and friends smudge part of the tree, this is not something we would want to even invalidate (IOW, it should always be up-to-date), so they serve different purposes. I still haven't looked at the read-tree yet, but as I outlined in a previous message, its intra-index merge could take advantage of cache-tree. "diff-index", especially "--cached" kind, also could use it to skip unchanged subtrees altogether. - : 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