Re: RFC: Subprojects

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 12, 2006, 13:38 UTC
Message-ID: <Pine.LNX.4.64.0601120826010.25300@iabervon.org>
In-Reply-To: <46a038f90601112046u13d7075dsc2108111e2462152@mail.gmail.com>

On Thu, 12 Jan 2006, Martin Langhoff wrote:

Show 10 quoted lines

> What about using nested checkouts? They work great with git as-is,
> just add an .gitignore file.
> 
> As Linus points out, there are many good reasons why a top-level
> commit should _not_ commit the nested subproject. And once you are
> observing that rule, what's left then? git status and git diff <HEAD>
> can show an aggregate of top-level and nested subprojects, but that's
> ease-of-use -- not something only.
> 
> What is your show stopper?

The core structural thing (which I'm not sure CVS handles) is having each commit of the outer project specify the commit of the inner project that it contains in some way. This would be good with CVS, but is vital with git, because there's no way of estimating it when you don't have a linear history. (With CVS, you could say that the inner project version for a given outer project version should be the version that was current when the outer project was committed. But that isn't well-defined for git.) If you try to debug anything involving the history, you'd have problems with choosing versions of the two projects that don't actually match.

	-Daniel
*This .sig left intentionally blank*