git clone and submodules

git clone and submodules

[Massimo Manca]

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

Hello,
on my windows notebook I have a local repo: h:\Repositories\RepoWR; it
contains 2 branches: the master and the 1.1.0 (that is a bug correction
branch). At now the 1.1.0 it is not merged on the master because we will
correct more other bugs (one bug -> one branch).

1. I need to clone the Repo, I mean the repo, working directory and
complete branches and history.
Actually to do this I must make a brutal copy of the RepoWR folder
because if I use git clone git doesn't clone also the master branch but
only the 1.1.0 branch that it is the active one (I used git checkout to
activate it).

So I am sure that I miss something and that this is a very common
situation, what I am doing wrong?

2. RepoWR will contain a complex project developed by several engineers
and made of some subprojects (already existent) and some libraries. I
would manage them as submodules, these are my intents:
a) the library mclib (about 50 c files) has its repo on a different
location, I would "connect" its repo inside RepoWR as a submodule
because I am sure that we need to modify/extend the library and we would
to have the ability to modify it and propagate modifications to its
repo, forcing all users of mclib to see the modifications and to repeate
their regression tests
How can implement this situation? Where can I find info or documentation?

b) every module (not more the 4-5 c files) will be developed and unit
tested, so normally every engineer makes a unit test project
implementing/using the module to test with TDD workflow. During the
progress of the work the modules must be added and committed to RepoWR;
the modules are on the working directory of RepoWR (RepoWR\src) and the
test files on a specific subfolder (RepoWR\TestModuleOne\src).
Is this a viable solution or are there hidden problems and so better
solution to implement?

[-- Attachment #2: massimo_manca.vcf --]
[-- Type: text/x-vcard, Size: 340 bytes --]

begin:vcard
fn:Massimo Manca
n:Manca;Massimo
org:Micron Engineering di Massimo Manca
adr:;;via della Ferriera, 48;Pordenone;PN;33170;ITALIA
email;internet:massimo.manca@micronengineering.it
tel;work:+39 0434 1856131
tel;fax:+39 0434 1851032 / 178 273 3543
tel;cell:+39 349 4504979
url:http://www.micronengineering.it
version:2.1
end:vcard

Re: git clone and submodules

[Jens Lehmann]

Am 16.06.2011 15:13, schrieb Massimo Manca:
> 2. RepoWR will contain a complex project developed by several engineers
> and made of some subprojects (already existent) and some libraries. I
> would manage them as submodules, these are my intents:
> a) the library mclib (about 50 c files) has its repo on a different
> location, I would "connect" its repo inside RepoWR as a submodule
> because I am sure that we need to modify/extend the library and we would
> to have the ability to modify it and propagate modifications to its
> repo, forcing all users of mclib to see the modifications and to repeate
> their regression tests

That sounds like submodules would fit in nicely here.

> How can implement this situation? Where can I find info or documentation?

http://progit.org/book/ch6-6.html
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#submodules

And for questions not answered there feel free to ask.

> b) every module (not more the 4-5 c files) will be developed and unit
> tested, so normally every engineer makes a unit test project
> implementing/using the module to test with TDD workflow. During the
> progress of the work the modules must be added and committed to RepoWR;
> the modules are on the working directory of RepoWR (RepoWR\src) and the
> test files on a specific subfolder (RepoWR\TestModuleOne\src).
> Is this a viable solution or are there hidden problems and so better
> solution to implement?

Did I get that right that the test files should not be put in the same
submodule (= directory tree) where the to-be-tested code lives? To me
it makes more sense when the tests and the code that is tested live in
the same submodule.