[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] CDT compile errors after update from CVC
|
On 3 Mar 2010, at 14:44, Michael Jackson wrote:
> They are using something like "Git subprojects" or sub modules or something like that. I can't find the email where it was explained to me. Maybe the Git repo for CDT needs to setup the same type of thing.
A git submodule is really a way of referencing a git project within a parent.
http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
The idea is that each subproject would be its own Git repository, and then the parent Git project merely has a pointer to the referenced submodules. In effect, the parent git project just becomes a list of pointers to Git tree commits (roughly speaking: repository versions or repository-wide tags) without storing any data.
The only reason to have a parent project is to store a marker which can be used across many individual Git projects on their release. For example, CDT might use the parent project to record when 6.0.1 and 6.0.2 were released, with pointers back to their child Git projects of their state when it happened.
The downside with a parent project is that to make sense of it, you really need to check out all the child projects, which in CDT's case might be prohibitive. In any case, it's fairly easy to add at a later stage (or indeed, throw it away afterwards if it's found to be useless) without affecting the individual child git repositories themselves.
The parent project can contain direct content (and not just pointers to other content), but it's fairly rare that this needs to happen, and is unlkely to be something that CDT needs to do.
So, you'd have:
cdt.git/
cdt.git/dsf.git/
cdt.git/core.git/
cdt.git/ui.git/
...
Each of the child projects would have their own revisions:
dsf.git@1.1
core.git@1.3
ui.git@2.4
In effect, cdt.git@1.1 then becomes a list "dsf.git@1.1, core.git@1.3, ui.git@2.4". The main reason is that if you release a newer version, you can record that (cdt.git@1.2 = dsf.git@1.4, core.git@1.7, ui.git@2.4") and then do recursive operations like 'git diff -r 1.1 -r 1.2' which in turn then does a piecewise diff of the child repositories.
Alex.
PS Git uses a SHA hash to identify its versions, rather than a human readable tag like 1.2; I used those as an example to get the concept across but the principle is the same, if a bit more long winded :-)
