Re: Project's repository infrastructure (sunbtree and submodules)

From: Nigel Magnay <nigel.magnay@gmail.com>
Date: Jun 11, 2008, 18:42 UTC
Message-ID: <320075ff0806111142g83d5ad4s4737d49b8af2dbf4@mail.gmail.com>
In-Reply-To: <20080609194203.06698e01@debian>

On Mon, Jun 9, 2008 at 4:12 PM, Armen Baghumian <armen@opensourceclub.org> wrote:

Show 29 quoted lines

> 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).