Thread (16 messages) flat view 16 messages, 9 authors, 2016-06-15

Re: RFC: Subprojects

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:42:16

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help