On Mon, Jun 9, 2008 at 4:12 PM, Armen Baghumian <armen@xxxxxxxxxxxxxxxxxx> 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). -- 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
