From: Johannes Schindelin Date: Wed, 11 Jan 2006 16:44:53 GMT Subject: Re: RFC: Subprojects Message-ID: In-Reply-To: <43C52B1F.8020706@hogyros.de> Hi, On Wed, 11 Jan 2006, Simon Richter wrote: > 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