threads / discuss / 13874

Project's repository infrastructure (sunbtree and submodules)

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

## tl;dr

3 messages between Jun 9, 2008 and Jun 11, 2008.

replies: 2people: 2as markdown or json

Armen Baghumian· Jun 9, 2008, 15:12 UTC · lore

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?

--Armen

[1] http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Armen Baghumian· Jun 11, 2008, 08:04 UTC · re: Armen Baghumian · lore

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

Hi,

Am I asking totally wrong question or asking it in wrong place? would you please point me to correct place or documentation.

--Armen

On Mon, 9 Jun 2008 19:42:03 +0430 Armen Baghumian <armen@OpenSourceClub.org> wrote:

Show 37 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?
> 
> --Armen
> 
> [1]
> http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Nigel Magnay· Jun 11, 2008, 18:42 UTC · re: Armen Baghumian · lore

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

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