Finn Arne Gangstad <finnag@xxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
