* Re: Project's repository infrastructure (sunbtree and submodules)
2008-06-09 15:12 Project's repository infrastructure (sunbtree and submodules) Armen Baghumian
@ 2008-06-11 8:04 ` Armen Baghumian
2008-06-11 18:42 ` Nigel Magnay
1 sibling, 0 replies; 3+ messages in thread
From: Armen Baghumian @ 2008-06-11 8:04 UTC (permalink / raw)
To: git list
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:
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Project's repository infrastructure (sunbtree and submodules)
2008-06-09 15:12 Project's repository infrastructure (sunbtree and submodules) Armen Baghumian
2008-06-11 8:04 ` Armen Baghumian
@ 2008-06-11 18:42 ` Nigel Magnay
1 sibling, 0 replies; 3+ messages in thread
From: Nigel Magnay @ 2008-06-11 18:42 UTC (permalink / raw)
To: Armen Baghumian; +Cc: git
On Mon, Jun 9, 2008 at 4:12 PM, Armen Baghumian
<armen@opensourceclub.org> 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).
^ permalink raw reply [flat|nested] 3+ messages in thread