Jonathan Nieder wrote: > Do you mean that you wish you could ignore subrepository boundaries > and use commands like > > git clone --recurse-submodules http://git.zx2c4.com/cgit > cd cgit > vi git/cache.h > ... edit edit edit ... > git add --recurse-submodules git/cache.h > git commit --recurse-submodules > git push --recurse-submodules > > , possibly with configuration to allow the --recurse-submodules to be > implied, and have everything work out well? Do you realize how difficult this is to implement? We'll need to patch all the git commands to essentially do what we'd get for free if the submodule were a tree object instead of a commit object (although I'm not saying that's the Right thing to do). Some caveats: - If we maintain one global index, and try to emulate git-subtree using submodules, we've lost. It's going to take freakin' ages to stat billions of files across hundreds of nested sumodules. One major advantage of having repository boundaries is separate object stores, indexes, worktrees: little ones that git is designed to work with. - Auto-splitting commits that touch multiple submodules/ superproject at once. Although git-subtree does this, I think it's horribly ugly. - Auto-propagating commits upwards to the superproject is another big challenge. I think the current design of anchoring to a specific commit SHA-1 has its usecases, but is unwieldy when things become big. We have to fix that first. -- 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