Re: RFC: Subprojects

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 11, 2006, 16:44 UTC
Message-ID: <Pine.LNX.4.63.0601111740220.17966@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <43C52B1F.8020706@hogyros.de>

Hi,

On Wed, 11 Jan 2006, Simon Richter wrote:

Show 6 quoted lines

> one thing that I have been missing so far in all SCM systems apart from CVS
> (and there it's just coincidence) is the ability to include a project as part
> of a bigger project. Developing software for embedded systems, I need that
> feature fairly often, for example the source tree for a particular device
> almost always contains one or more Linux trees, some binutils, gcc and gdb
> stuff and so on.

What I do: I call it a branch. While this might seem technically incorrect, it is not.

And since the subprojects are really independent, you can connect them by an octopus.

> The changes necessary here would be fairly simple: "tree" objects would point
> to a "commit" or a "tag" object when a subproject is used.

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?

Remember: trees, commits and tags (objects in general) are immutable. You 
may think that you just commit a new revision of the subproject, and it is 
picked up by the overall project, but that is not the case!

> In the working directory, this would be represented by a .git directory that
> contains a symref to the embedding project instead of the objects directory.
> Head pointers are only required if you intend to push changes upstream to the
> maintainer of the embedded project. Each subproject has its own index.

You can do this like I said: use branches (and possibly a common GIT_OBJECT_DIRECTORY to save on disk space).

Hth, Dscho