Hi, Just another question: What if your dependency is used in many projects? For example if you use it in 10 projects it will be checked out 10 times. Well you could always do a push (and a pull in all other 9 projects to not forget them). Ok 10 projects is quite much, but I sometimes have 2-4 projects in parallel which sometimes use the same dependencies. (And change them in the projects on demand) I've thought about checking out the dependency only once and do hardlinking, I've also read about the "git clone --shared", but with both methods I would loose the advantage of using submodule and on the other side I don't know exactly which problems could arise. Could I just say that submodules would be checked out to a central location or are there better possibilities? I don't mind the disk space, I just wonder how to keep track if you have some projects all using the same dependencies. Thanks, Harald > -----Ursprüngliche Nachricht----- > Von: Harald Heigl [mailto:Harald@xxxxxxxxxxxxxxx] > Gesendet: Mittwoch, 01. Februar 2012 22:07 > An: 'git@xxxxxxxxxxxxxxx' > Betreff: AW: Project structure of .NET-Projects using git submodule or > something different > > Hi, thanks for your answer! > > > -----Ursprüngliche Nachricht----- > > Von: Jens Lehmann [mailto:Jens.Lehmann@xxxxxx] > > Gesendet: Mittwoch, 01. Februar 2012 21:30 > > An: Harald Heigl > > Cc: git@xxxxxxxxxxxxxxx > > Betreff: Re: Project structure of .NET-Projects using git submodule or > > something different > > > > Am 31.01.2012 23:41, schrieb Harald Heigl: > > > Let's assume following Project structure (Dependencies and > > Subdependencies > > > are submodules and submodules of the submodules) > > > Project > > > Dependency 1 > > > Dependency 2 > > > Dependency 3 > > > Dependency 4 > > > Dependency 2 > > > > > > > > > The problem is if I want to build them I need to build 2+3, then 1, 4 and 2 > > > again and then the project. As you may see project 2 is a submodule of > > > dependency 1 and also of project. I don't feel comfortable with this > setup. > > > What do you think? > > > > Hmm, we try to avoid that kind of setup as having checked out different > > versions of the "Dependency 2" submodule could have rather surprising > > effects. We get along really well with "Dependency 2" only being present > > in the superproject and having "Dependency 1" reference that instead of > > having its own copy (So we have submodules which are depending on > having > > other submodules right next to them). Then the superproject is > responsible > > for tying it all together. > > I think you're right, my first thoughts were that if I start a new project I just > "git submodule dependency1" and get all the required dependencies and > the dependencies within the dependencies and so on ... . > With your solution I "git submodule dependency1" and have to think about > the dependencies it depends on. On the other hand we are just a small > company and the number of submodules is not too big and the missing > references in a new project would be easily identifiable, so ... . > > And if I want to checkout dependency 1 individually (for whatever reason), I > could still do something like this: > SuperDependency1 (with solution-File) > Dependency1 (as submodule) > Dependency2 (dependency of dependency1 - as submodule) > Dependency3 (dependency of dependency1 - as submodule) > > Thanks again, I see my concept causes some trouble ... > > Any other thoughts or other workflows with git or with tools build around > git? > > Thanks again, > Harald -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html