| > Are there some fundamental aspects of git that would make it either very difficult to improve that, or that would sacrifice some important benefits if they were made? I can't speak to improving git, but I think some light on this area can be shed by Linus' tech talk at Google in 2007. 1. Linus says there's a specific focus on full history and content, not files ... so it's a deliberate, different axis of focus than file count: https://youtu.be/4XpnKHJAok8?t=2586 ... AND it's a specific pitfall to avoid when using Git: https://youtu.be/4XpnKHJAok8?t=4047 2. As Linus tells it, Git appears to be designed specifically for project maintenance while not getting in the way of individual commits and collaboration. But the global history and more expensive operations on things like "who touched this line" are deliberate so lines of a function are tracked across all moves of the content itself. Maintainer tool enablement: https://youtu.be/4XpnKHJAok8?t=3815 Content tracking slower than file-based "who touched this": https://youtu.be/4XpnKHJAok8?t=4071 === I have no answer, but ... Practically, I've used lazy filesystems both for Windows-on-Git via GVFS [1][2] and Google's monorepo jacked into a mercurial client (I think that's what it is?). Both companies have made this work, but as Linus says, a lot of the stuff just doesn't work well with either system. Windows-on-Git still takes a lot of time overall, and stacking > 10 patches of an exploratory refactor with the monorepo on hg starts slowing WAY WAY down to the point where any source control operations just get in the way. [1] https://devblogs.microsoft.com/devops/announcing-gvfs-git-vi... [2] https://github.com/microsoft/VFSForGit |