Re: RFC/RFH submodule handling in big setups

["Nigel Magnay" <nigel.magnay@gmail.com>]

Do you currently use svn?
This feels like the common technique of using svn:externals, where
product1 has
foo repo/foo/trunk
os-abstraction-lib repo/os-abstraction-lib/trunk

product2 has
os-abstraction-lib repo/os-abstraction-lib/trunk
log-merger repos/log-merger/trunk

Where git (if I understand submodules correctly) can't do the above,
because the links are to SHA1s rather than tags or names, so in svn
terms it'd be something like
os-abstraction-lib repo/os-abstraction-lib/trunk@xxx
log-merger repos/log-merger/trunk@yyy

At first I thought the option (4) you suggest (Manually push all
sub-modules to some new branch before pushing the  super-module) was
going to be a pain - but actually I came to the conclusion it was
actually better. In our svn world, commits to shared libraries (can)
cause all hell to break loose - it'd actually be an advantage to have
to promote changes into the supermodules (the products in our case).




On Jan 7, 2008 7:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Finn Arne Gangstad <finnag@pvv.org> writes:
>
> > We're trying to get git to work well with our vision of submodules,
> > and have to figure out how to make submodule fetching and pushing work
> > in a smooth way.
> >
> > This is our situation (simplified):
> >
> >           [product1]          [product2]  ...         (supermodules)
> >            /      \             /     \
> >     ... [foo]  [os-abstraction-lib] [log-merger] ...  (submodules)
> >
> >
> > A developer does a modification to the os-abstraction-lib, and a
> > modification to the log-merger that depends on the change in the
> > os-abstraction-lib. He wants this into product2, and doesn't know or
> > care about product1.  He doesn't know whether his modification is
> > acceptable or not, or whether his modification will go in before some
> > other modification.
> >
> > He needs some way of pushing his modifications to a branch in the
> > supermodule (e.g. "change-131345"), without interfering with anyone
> > else.  The problem is where to push the sub-modules, they need to be
> > available for anyone who wants to get the "change-131345" branch of
> > the product2, but the modifications shouldn't show up anywhere else
> > (yet).  Here are solutions we have thought of so far:
>
> The phrase "without interfering with anyone else" feels somewhat
> wrong and I sense there is something missing in the description
> of the workflow.  When a developer pushes a change to somewhere
> else, it must be because the change needs to be shared with
> _somebody else_ (but not necessarily with _everybody_).
>
> Without knowing exactly what the desired workflow is, I'd hazard
> a guess and would recommend something else, which is  hopefully
> a more useful way.
>
> When the developer makes that 131345 change in os-lib submodule,
> he is acting as a developer of that library and advancing its
> state.  He wants to add an enhancement so that a particular way
> to use it elsewhere (his use in log-merger program perhaps being
> the first one of them) can be supported, but the change is not
> accepted as the project wide one from os-lib project's point of
> view.  The change needs to be shared with people in product2
> group that want to further work on top of the change he makes in
> log-merger project, but not necessarily with everybody in
> product2 group, let alone people in product1 group.
>
> That's exactly what a topic branch is about, isn't it?
>
> He has a topic to enhance something in os-lib project, so
> whatever the mysterious 131345 can be made into one branch in
> os-lib project and given a more meaningful topic name.  He can
> push that out to os-lib project, and bind its tip in his tree of
> product2 superproject at os-lib directory, and push it to
> produc2 repository (maybe to its 'master', or maybe also to its
> one of the topic branches that houses his work-in-progress).
>
> That way, when somebody from product2 group needs to work on top
> of the change he made and pushed out thusly updates, his copy of
> os-lib will get the updates to (or perhaps creation of) the
> topic branch that contains 131345 change, and he can start
> working from where the original developer left off.  He can even
> fix bugs in the change in that 131345 topic in os-lib project
> the original developer made, push that back, and the original
> developer can build on top of that change.
>
>
> -
> 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
>