Re: RFC: Subprojects

From: Linus Torvalds <torvalds@osdl.org>
Date: Jan 11, 2006, 17:42 UTC
Message-ID: <Pine.LNX.4.64.0601110928350.5073@g5.osdl.org>
In-Reply-To: <43C537C9.4090206@hogyros.de>

On Wed, 11 Jan 2006, Simon Richter wrote:

> 
> The important thing for me is that I need to be able to transfer them easily,
> or turn a subdirectory into a subproject or vice versa.

Turning a _snapshot_ of a subproject into a subdirectory is easy: you can literally just create a subdirectory, copy it there, and it will re-use all the objects that the subproject uses (ie the top-level project will have a "tree" entry that just points to the same tree entry as the top-level commit in the sub-project).

However, while that works as a way to import snapshots, it doesn't work in any other way. It allows you to share objects with the "real project", and it's space-efficient etc, but there's no shared history, and you cannot merge back-and-forth, which is probably what you really want to do.

Quite frankly, you really probably want more of a "git-aware symlink" kind of thing. I'd really hesitate (in fact, I'd object) to re-use the existing "tree" type for it, but you're not the only one to have asked for subproject support, so this is clearly not a odd request.

Show 5 quoted lines

> > Sorry, we discussed similar things already. It is not necessary to change
> > the structure. Even more: it makes no sense. Why would you want to have two
> > or more commit messages for the same revision?
> 
> Because the commit affects both the subproject and the master project.

What we _could_ do is for you to first do a commit in the "independent" subproject (it really would be a totally independent git repository in all ways: you could continue to merge it with other subprojects of the same type), and then you could commit a new pointer to that subproject in the master project.

The two would really be fundamentally independent: they'd be two different git projects, one would just have a strange kind of "symlink" to the other, which would include a name and the top commit SHA1 of the other project.

Getting everything to work reasonably seamlessly would be potentially painful (getting "git diff" to recurse into the subdirectory correctly is non-trivial: you'd have a separate ".git/index" file for it), but it sounds doable.

I'd suggest adding a new kind of object ("gitlink") which has some well-specified format (20-byte SHA1 + ASCII C string "name" - the name translation to external repository would be done in the .git/config file of the "outer" project). Then a special file mode to indicate that in the "struct tree", and support for "git-update-cache" to understand how such an object is really tied into the "<pathname>/.git/HEAD" file rather than the rest of the directory contents.

Then a "git fetch" would have to be taught to recursively fetch the other subproject when the "gitlink" changes.

It should be doable: somebody could try to implement a rough first draft (maybe not very seamless at first).

		Linus