From: Nigel Magnay Date: Wed, 11 Jun 2008 18:42:33 GMT Subject: Re: Project's repository infrastructure (sunbtree and submodules) Message-ID: <320075ff0806111142g83d5ad4s4737d49b8af2dbf4@mail.gmail.com> In-Reply-To: <20080609194203.06698e01@debian> On Mon, Jun 9, 2008 at 4:12 PM, Armen Baghumian wrote: > Hi, > > I have several projects which each project contains several modules. > modules are shared between projects. > > For example let say there is three modules A, B, and C, and two > project called P1 and P2. P1 uses A and B modules and P2 uses B and C. > > I want to have centralized place to clone/pull/push in P1 and P2 and it > would be nice to push changes in modules(A,B,C) from projects > (P1,P2) so when changes in B pushed from P1 it could be pulled from P2 > (think B as a shared module between P1 and P2). > > As far as modules are not big enough I don't want to push changes > directly in to those repositories. > > To solve the problem I just create three separated repositories for > each modules (A,B,C) and create two other repositories for each project > and use git-submodule to add modules in each repository. > > pushing changes to modules(A,B,C) are really error prone and annoying > so I searched for a better way to solve that problem. > > Seems subtree merge[1] is other choice but I'm not sure. > > 1) What is best way to solve such situation? > 2) If subtree is best choice how to push changes to modules(A,B,C) from > projects? > What we do (and I'm not sure it's best - but it works for us), is as you describe :- repositories for the modules A,B,C, and use those as submodules in projects P1 and P2. In each project P1, A, B there's a branch 'p1', and in each project P2, B, C there's a branch 'p2'. That way changes can be committed to B independently, and not conflict. The 'owner' of B is responsible for merging back to 'master' (which is the basis for any future project P3). The git submodule commands are, however, quite verbose. There's a lot of typing, especially compared to svn, and it's particularly annoying for the user to update P1, and find A, B are no longer on branch p1, but have been reset to (no branch). That said, the infrastructure is there, it just needs someone to think for a bit to work out what scripts would help most people's workflow (e.g : treat a superproject as if the subprojects don't really exist).