Can you develop directly in Git submodules?

You can develop directly from a submodule (as I explained in true nature of submodules ) But each time you commit something in the submodule (and publish it somewhere), you need to make sure to commit as well in the parent repository.

You can develop directly from a submodule (as I explained in "true nature of submodules"). But each time you commit something in the submodule (and publish it somewhere), you need to make sure to commit as well in the parent repository. Now you have two submodules organizations: recursive includes A Common (Common could depend itself on other dependencies) B Common ... or direct includes (direct dependencies only) ParentA A Common Other A dependencies ParentB B Common Other B dependencies (Actually, if Common had dependencies of its own, A or B would depend on "ParentCommon" which would refer to Common and all its direct dependencies) Unless you have a structural imperative where Common must be a subdirectory of A, I would recommend the second organization, which is closer to your C:\dev\A, C:\dev\Common one.

Actually, I prefer only one depth dependencies, where for ParentA, I list all dependencies, direct and indirect, as submodules. That is because, with any tool attempting to manage dependencies, you will still need to make decisions on: dependencies conflicts (A depends on X which needs Z1, and Y which needs Z2: which version of Z do you want to use/compile in your project? ) dependencies override (when A depends on X which needs Z1, whereas A also choose to use X2) dependencies cycle (where A depends on B which relies on C which uses... A!).

– kelloti Feb 15 '11 at 18:15 @kelloti: yes, submodules would be listed under, for instance 'ParentCommon. – VonC Feb 15 '11 at 18:16.

Submodules are not something that works particularly smoothly, the way you intend it here. As you've probably noticed, to commit a change to a project in a submodule (as of Git v1.7, probably in perpetuity), you need to: Make the change in the submodule. Commit to the submodule, getting a new SHA hash.

Update the outer project's . Gitmodules file with the new hash. Commit to the outer project.

This is cumbersome if you're developing the submodule and the outer project(s) in lockstep. It's "the right way," as far as preferring stable software configurations over simplicity when mixing codebases, but the command sequence is pathologically long in this case. Popping the why stack, though, lockstep development with submodules probably indicates one of several larger problems: You do not have a clear interface between your subcomponent, and implementation details leak across the boundaries.

You do not have a well-thought interface to your subcomponent, so you keep having to reinvent things as you solve a more interesting problem. Your interface is stable and high-quality, but you do not have good QA process on the submodule code, so instead you're constantly fixing that while trying to get other work done. (Esp.

If A and B keep changing different things) Your "common" code is actually much smaller than you think, or should be divided differently. None of these cases are necessarily true of you, but these are among the problems that cause the horrible lockstep submodule update workflow you're having. Submodules work pretty well when you could almost rely on shared libraries and header files, but there's some compelling reason (e.g. Weird compile flags that must be consistent) to compile from source.

My approach would be to fix these problems, if they're the real root causes. If these problems aren't there, however, it may be that git is the wrong tool for you.It pains me to say it, but this is definitely a possibility.

1 In other words, source dependency is hard to manage, whereas binary dependency, where you rely on a specific version of a build (of the sources) is better. In which case, you need to reference binaries through an repository outside Git (like Nexus for instance). – VonC Feb 15 '11 at 18:19 regardless of the problems that our process might have, simply being able to know that project A's a5b2c79 requires Common's 7fc95b6 is worth a ton when it comes to maintaining production & development branches.

– kelloti Feb 15 '11 at 18:21 @kelloti I mean, fine, if the benefit of git is so compelling, you'll have to fix something else. Either a) Invest in fixing your codebase, to avoid lockstep development or b) Ivest in some hooks or scripts (maybe the sort Jefromi linked) that make the tool work for you. – Andres Jaan Tack Feb 16 '11 at 10:27.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.