Re: RFC/RFH submodule handling in big setups

[Junio C Hamano <gitster@pobox.com>]

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.