Am 13.12.2011 15:17, schrieb Phil Hord: > On Mon, Dec 12, 2011 at 2:36 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > [...] >> Distro package dependency tracking is a poor analogy for many reasons, but >> I'll only touch a few. > [...] >> Naively, one might think that two branches, branch-1.0 and branch-2.0, can >> be defined in the repository of L, tell somebody (like "superproject that >> covers all the packages in the distro") that A wants branch-1.0 and B >> wants branch-2.0 of L respectively, to emulate this, but if one thinks >> further, one would realize that it is insufficient. For one thing, it is >> unclear what should happen when both A and B are asked to be checked out, >> but more importantly, in dependency requirements on real distro packaging, >> the application C could say "I want v1.0 API but v1.4 is broken and not >> compatible with me", which won't fit on the two-branches model. A >> workaround to add more branches to L could be devised but any workaround >> cannot be a good solution that allows a random application C among 47 >> others to dictate how the branch structure of L project should look like. >> >> Fortunately, the dependency management is a solved problem by distro >> package management and build systems, and they do so without using >> anything from submodules. There is no point reinventing these logic in git >> submodules and emulating poorly. >> >> The only remotely plausible analogy around distro packaging would be a >> superproject full of all the packages in a distro as its submodules, and >> records exact versions of each and every package that goes on a release >> CD (or DVD). In that case, you do want to have a central registry that >> records what exact version of each package is used to cut the CD and the >> mother of all modules superproject could be one way to implement it. But >> that is not an example of floating, but is a direct opposite. >> >> This exchange convinced me further that anybody who wishes to use >> "floating" is better off either by doing one or both of the following: >> >> - using "exact" but not updating religiously, as the interdepency >> requirement in their project is not strict; or >> >> - not using submodules at all, but merely keeping these unrelated A, B, C >> and L as standalone repositories next to each other in the directory >> structure. > > My interdependency requirements are not so cut-and-dry. We use > submodules to isolate controlled regions of code. We may need to > share our project with a contractor who is allowed to see code > pertaining to "vendorA" but not that for "vendorB" or "VendorN". But > our in-house developers want to have all the vendor code in one place > for convenient integration. Submodules do this nicely for us. We can > give the contractor just the main modules and the VendorA modules and > he'll be fine. In-house devs get all the submodules (using the > vendor-ALL superproject). > > But this necessarily means there is too much coupling for comfort > between our submodules. For example, when an API changes in the main > submodule, each of the vendor submodules is affected because they each > implement that API in a custom method. Some of those vendor modules > belong to different people. Submodule synchronization becomes a real > chore. Hmm, maybe having vendor-specific branches in the superproject would help here. But that is hard to tell without knowing more details about your setup. But I suspect your vendor-ALL superproject is exactly the right spot to deal with these kind of problems (and if that isn't easy that might be a result of the difficulty of the problem you are trying to solve here, keeping different vendors in sync with your API ;-). > Floating would help, I think. Instead I do this: > > git pull origin topic_foo && git submodule foreach 'git pull origin topic_foo' > > git submodule foreach 'git push origin topic_foo' && git push origin topic_foo This sounds to me like you would need the "--recurse-submodules" option implemented for "git pull" and "git push", no? And I miss to see how floating would help when the tips of some submodules are not ready to work with other submodules tips ... > But not all my developers are git-gurus yet, and they sometimes mess > up their ad hoc scripts or miss important changes they forgot to push > in one submodule or another. Sure, even though current git should help you some by showing changes in the submodules. > Or worse, their pull or push fails and > they can't see the problem for all the noise. So they email it to me. We circumvent that by not pulling, but fetching and merging in the submodule first and after that in the superproject. You have much more control about what is going wrong where (and can have more git-experienced people help with - or even do - the merges). > On my git server, I have a hook that automatically propagates each > push to "master" from the submodules into the superproject. But this > is tedious and limited. And it relies on a centralized server. But for closely related stuff that is a good option. Our continuous integration server shows us quite some breakage between submodules before they hit a superproject, which is really helpful. > You may say this itch is all in my head, but it sure seems real to me. This definitely is a real problem. Lets see how far git can help you here... -- 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