Nigel Magnay schrieb: > On Wed, Jul 16, 2008 at 11:47 AM, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> wrote: >> Nigel Magnay schrieb: >>> For me, in some really high proportion of cases, I think I want 'git >>> commit' to mean 'commit to any child repositories, any sibling >>> repositories, and any parent repositories (updating the submodule sha1 >>> as appropriate). In other words, 'pretend like the whole thing is one >>> big repo'. >> And I think that this is the problem: If this way of commiting your >> changes is *required* in the *majority* of cases, then you are IMO outside >> the intended use-case of submodules. You are better served by really >> making this one big repo. >> > > Hm - then my contention is that the scope of submodules needs to be > expanded (or something needs to be built on top). > > One-big-repo doesn't fly - > 75% of the code volume (the 'other' > modules) are shared between multiple projects. In SVN these are just > svn:externals (which has it's own imperfections). > > I think it's a common usecase. You have 'shared' modules and > 'project-specific' modules[*]. The 'shared' modules you hope don't > change very much, but they are part of the overall project > configuration - it's really nice that you can branch so easily in git, > then get the module owner to merge those changes into the next release > at their leisure. The superproject then represents the correct > configuration of submodule trees to make a valid build. Ah, is this your actual scenario? Just to make sure we are talking about the same thing: - You own superproject P. - $Maintainer owns submodule S. - You use S in P. - You make changes to S that you would like $Maintainer to include in the next release. x You use in P your changes to S while $Maintainer has not yet released a new version of S with your changes. - Finally your changes arrive via the new release of S. That *is* the intended use-case for submodules. But you have to play the game by the rules: - $Maintainer defines the official states of S. - You must never commit an unofficial state of S in P. The critical step in above list I marked with x: - During the period where only *you* have the new changes to S, you must *not* commit your submodule state to P. Instead, you write P in such a way that it can work with both the old version of S and the upcoming release that will have your changes[*]. This way you make sure that your consumers of P always have a working version regardless of which version of S they use. - After you have received the new release of S from $Maintainer, you commit the new state of S in P. And if you are nice to your consumers of P, then you *do not* remove the workaround from P just yet, so that you don't force them to upgrade S. You will remove it later only if it becomes a maintainance burden. [*] If it is not possible to make P work with old and new versions, then you have to work closely with the $Maintainer so that you never need commit an unofficial state of S into P. -- Hannes -- 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
