"Bahadir Balban" <bahadir.balban@xxxxxxxxx> writes: > ... I said "performance reasons" assuming all the > file hashes need checked for every commit -a to see if they're > changed, but I just tried on a PIII and it seems not so slow. Ok. Other people have already cleared the fear for 'commit' case, so I hope you are happier. There is one thing we could further optimize, though. Switching branches with 100k blobs in a commit even when there are a handful paths different between the branches would still need to populate the index by reading two trees and collapsing them into a single stage. In theory, we should be able to do a lot better if two-tree case of read-tree took advanrage of cache-tree information. If ce_match_stat() says Ok for all paths in a subdirectory and the cached tree object name for that subdirectory in the index match what we are reading from the new tree, we should be able to skip reading that subdirectory (and its subdirectories) from the new tree object at all. Anybody interested to give it a try? - 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