People who make filesystems test this stuff and will be able to tell you the ballpark figure for performance of this kind of operation even w/o testing. Testin

People who make filesystems test this stuff and will be able to tell you the ballpark figure for performance of this kind of operation even w/o testing. Testing here isn't the problem... The problem here is that we need a reasonably small interface for filesystem to enable competing implementations, so, for example, we don't have a filesystem interface for bulk metadata operations, because this is an unusual request (most user-space applications which consume filesystem services don't need it). So, we can only query individual files for metadata changes through "legal" means (i.e. through the documented interface). And now you end up in a situation where instead of fetching all the necessary information in a single query, the performance impact of your query scales linearly with the number of items queried. Even if Git developers anticipated this performance bottleneck, there's not much they can do w/o doing some other undesirable stuff. Any solution created outside of the filesystem would risk de-synchronization with the filesystem (i.e. something that watches the state of the filesystem dies and needs to be restarted, either loosing old changes or changes done between the restarts). Another solution could try going behind the documented filesystem interface, and try to salvage this information directly from the known filesystems... which would be a lot of work compounded with the potential to screw up your filesystem. Maybe if we'd have Git integrated with the kernel and be able to thus integrate better with at least the in-kernel filesystems. But this would still put people on anything but Linux at a disadvantage, and even on Linux, if you wanted some filesystem that's not in the kernel, you'd also have the same problem...