Re: Composing git repositories

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.