Re: [PATCH 0/6] Initial subproject support (RFC?)

On Tue, 10 Apr 2007, Alex Riesen wrote:

Note that I was definitely planning on adding them too, but they are at a higher level.

So the long-term plan is/was to add a flag to "git diff" (and "git ls-tree" etc) to say "recurse into subprojects".

You cound perhaps even make that flag the default with some .git/config option, if your superproject is small enough.

But this series of 6 (and the seventh ugly hack) is literally meant for just the really core object-handling stuff, and even there it's not really complete.

For example, you cannot even clone a superproject yet, simply because git-upload-pack doesn't know that it's not supposed to follow the gitlink things etc. So there's a lot of details left even for the really *core* stuff, but I wanted to post the series of six patches because those six patches are actually enough to reach the point where you can start looking at individual problems (like "git upload-pack") and fix them incrementally.

So I'd like this to be merged somewhere, not because "it works" or "it's complete", but because it's in a shape where I think a lot of people can start fixing small details.

For example, with just two smallish updates:
 - teach "git upload-pack" not to try to follow gitlinks
 - teach "git read-tree" to check out a git-link as just an empty 
   subdirectory
you should already be pretty close to being able to clone a superproject. 
You'd still have to clone the subprojects one-by-one manually, and that 
would be more of a porcelain'ish issue to teach git clone to fetch 
submodules too (with some ".gitmodules" file that contains the rules for 
that!)

But no, I didn't do any of that. I literally did just the "tree object format change" to support the *notion* of gitlinks - not all the pieces to then actually *implement* the notion are done by a long shot.

I think everybody agrees that we need some kind of subproject support, and the KDE repository certainly shows that subprojects need to be truly independent (because if they aren't, you end up with all the scaling issues that we see now - including something as simple as just "fsck" taking way way too long unless you have 4GB of RAM or more), and this sets the basic rules for that.

But they really are pretty low-level rules. For example, to go back to the KDE thing: we'd also need to teach *importers* to import certain subdirectories as submodules (or have a git->git translator that turns a subdirectory into a separate submodule).

So those are examples of things that obviously need to be done, and that my patches do not address in *any* way. They are really low-level plumbing support, kind of like the old original days when you had to run

	git-update-index ...
	tree=$(git-write-tree)
	commit=$(git-commit-tree -p $parent $tree <$msgfile)

by hand. A few monts later it was "git commit -a", but it started out with just fairly low-level plumbing..

		Linus