{"thread":{"id":"11506","subject":"RFC/RFH submodule handling in big setups","startedAt":"2008-01-07T10:23:27Z","lastAt":"2008-01-07T21:51:05Z","messageCount":8,"participants":["Finn Arne Gangstad","Junio C Hamano","Jan Hudec","Nigel Magnay"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"64640","messageId":"20080107102327.GA12427@pvv.org","threadId":"11506","inReplyTo":null,"subject":"RFC/RFH submodule handling in big setups","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2008-01-07T10:23:27Z","receivedAt":"2008-01-07T10:23:27Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"We're trying to get git to work well with our vision of submodules,\nand have to figure out how to make submodule fetching and pushing work\nin a smooth way.\n\nThis is our situation (simplified):\n\n [product1] [product2] ... (supermodules)\n / \\ / \\\n ... [foo] [os-abstraction-lib] [log-merger] ... (submodules)\n\n\nA developer does a modification to the os-abstraction-lib, and a\nmodification to the log-merger that depends on the change in the\nos-abstraction-lib. He wants this into product2, and doesn't know or\ncare about product1. He doesn't know whether his modification is\nacceptable or not, or whether his modification will go in before some\nother modification.\n\nHe needs some way of pushing his modifications to a branch in the\nsupermodule (e.g. \"change-131345\"), without interfering with anyone\nelse. The problem is where to push the sub-modules, they need to be\navailable for anyone who wants to get the \"change-131345\" branch of\nthe product2, but the modifications shouldn't show up anywhere else\n(yet). Here are solutions we have thought of so far:\n\n1. push and fetch sha1s directly - this was sort of vetoed on this list.\n\n2. each time you push a submodule, push it to a auto-generated\n tag (something like submodule-autogen-), and use fetch -t\n when fetching the submodules\n\n Issue: Need to clean up these tags at some point, or there will be too\n many of them. There will be many ugly tags no matter what.\n\n3. each time you push a submodule, do a merge ours to a\n \"internal-submodule-tracking\" branch, and push to that. Something\n like this in other words:\n\n git fetch origin internal-submodule-tracking\n git merge -s ours origin/internal-submodule-tracking\n git push origin internal-submodule-tracking\n git reset --hard HEAD^1\n\n Issue: feels wrong somehow?\n\n4. Manually push all sub-modules to some new branch before pushing the\n super-module. This is what we'd rather avoid, but the developer\n should obviously have the option of doing this to some sub-modules\n if he wants to.\n\n5. Secret option 5 - something we didn't think about\n\n- Finn Arne\n"},{"id":"64661","messageId":"7vr6gtzaeq.fsf@gitster.siamese.dyndns.org","threadId":"11506","inReplyTo":"20080107102327.GA12427@pvv.org","subject":"Re: RFC/RFH submodule handling in big setups","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-07T19:46:21Z","receivedAt":"2008-01-07T19:46:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Finn Arne Gangstad writes:\n\n> We're trying to get git to work well with our vision of submodules,\n> and have to figure out how to make submodule fetching and pushing work\n> in a smooth way.\n>\n> This is our situation (simplified):\n>\n> [product1] [product2] ... (supermodules)\n> / \\ / \\\n> ... [foo] [os-abstraction-lib] [log-merger] ... (submodules)\n>\n>\n> A developer does a modification to the os-abstraction-lib, and a\n> modification to the log-merger that depends on the change in the\n> os-abstraction-lib. He wants this into product2, and doesn't know or\n> care about product1. He doesn't know whether his modification is\n> acceptable or not, or whether his modification will go in before some\n> other modification.\n>\n> He needs some way of pushing his modifications to a branch in the\n> supermodule (e.g. \"change-131345\"), without interfering with anyone\n> else. The problem is where to push the sub-modules, they need to be\n> available for anyone who wants to get the \"change-131345\" branch of\n> the product2, but the modifications shouldn't show up anywhere else\n> (yet). Here are solutions we have thought of so far:\n\nThe phrase \"without interfering with anyone else\" feels somewhat\nwrong and I sense there is something missing in the description\nof the workflow. When a developer pushes a change to somewhere\nelse, it must be because the change needs to be shared with\n_somebody else_ (but not necessarily with _everybody_).\n\nWithout knowing exactly what the desired workflow is, I'd hazard\na guess and would recommend something else, which is hopefully\na more useful way.\n\nWhen the developer makes that 131345 change in os-lib submodule,\nhe is acting as a developer of that library and advancing its\nstate. He wants to add an enhancement so that a particular way\nto use it elsewhere (his use in log-merger program perhaps being\nthe first one of them) can be supported, but the change is not\naccepted as the project wide one from os-lib project's point of\nview. The change needs to be shared with people in product2\ngroup that want to further work on top of the change he makes in\nlog-merger project, but not necessarily with everybody in\nproduct2 group, let alone people in product1 group.\n\nThat's exactly what a topic branch is about, isn't it?\n\nHe has a topic to enhance something in os-lib project, so\nwhatever the mysterious 131345 can be made into one branch in\nos-lib project and given a more meaningful topic name. He can\npush that out to os-lib project, and bind its tip in his tree of\nproduct2 superproject at os-lib directory, and push it to\nproduc2 repository (maybe to its 'master', or maybe also to its\none of the topic branches that houses his work-in-progress).\n\nThat way, when somebody from product2 group needs to work on top\nof the change he made and pushed out thusly updates, his copy of\nos-lib will get the updates to (or perhaps creation of) the\ntopic branch that contains 131345 change, and he can start\nworking from where the original developer left off. He can even\nfix bugs in the change in that 131345 topic in os-lib project\nthe original developer made, push that back, and the original\ndeveloper can build on top of that change.\n"},{"id":"64662","messageId":"20080107200756.GA20892@efreet.light.src","threadId":"11506","inReplyTo":"20080107102327.GA12427@pvv.org","subject":"Re: RFC/RFH submodule handling in big setups","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-01-07T20:07:56Z","receivedAt":"2008-01-07T20:07:56Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Jan 07, 2008 at 11:23:27 +0100, Finn Arne Gangstad wrote:\n> 3. each time you push a submodule, do a merge ours to a\n> \"internal-submodule-tracking\" branch, and push to that. Something\n> like this in other words:\n> \n> git fetch origin internal-submodule-tracking\n> git merge -s ours origin/internal-submodule-tracking\n> git push origin internal-submodule-tracking\n> git reset --hard HEAD^1\n> \n> Issue: feels wrong somehow?\n\nOnly one thing feels wrong here -- the merge -s ours. For one thing, the\ncommit is probably descendant of what was in the internal-submodule-tracking\nbranch (the branch name should actually have product2 in it's name).\nIf it is not, you should not artificially make it so, but rewind the branch.\n\nBut as Junio already told you, you should really manage the subproject like\na project (because it is a project), so the change should get to a topic\nbranch where the other superprojects can look at the change and decide\nwhether they want it or not.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"64663","messageId":"320075ff0801071208u1900bf76q2f0dc9cb0dc4318b@mail.gmail.com","threadId":"11506","inReplyTo":"7vr6gtzaeq.fsf@gitster.siamese.dyndns.org","subject":"Re: RFC/RFH submodule handling in big setups","fromName":"Nigel Magnay","fromEmail":"nigel.magnay@gmail.com","sentAt":"2008-01-07T20:08:38Z","receivedAt":"2008-01-07T20:08:38Z","isPatch":false,"sender":{"key":"nigel.magnay@gmail.com","avatar":"https://gravatar.com/avatar/d85cf38287bef3a8e4fa02358d2756d7589f8676c5eeb881ce2f6d731e4526c3?d=mp&s=160"},"body":"Do you currently use svn?\nThis feels like the common technique of using svn:externals, where\nproduct1 has\nfoo repo/foo/trunk\nos-abstraction-lib repo/os-abstraction-lib/trunk\n\nproduct2 has\nos-abstraction-lib repo/os-abstraction-lib/trunk\nlog-merger repos/log-merger/trunk\n\nWhere git (if I understand submodules correctly) can't do the above,\nbecause the links are to SHA1s rather than tags or names, so in svn\nterms it'd be something like\nos-abstraction-lib repo/os-abstraction-lib/trunk@xxx\nlog-merger repos/log-merger/trunk@yyy\n\nAt first I thought the option (4) you suggest (Manually push all\nsub-modules to some new branch before pushing the super-module) was\ngoing to be a pain - but actually I came to the conclusion it was\nactually better. In our svn world, commits to shared libraries (can)\ncause all hell to break loose - it'd actually be an advantage to have\nto promote changes into the supermodules (the products in our case).\n\n\n\n\nOn Jan 7, 2008 7:46 PM, Junio C Hamano wrote:\n> Finn Arne Gangstad writes:\n>\n> > We're trying to get git to work well with our vision of submodules,\n> > and have to figure out how to make submodule fetching and pushing work\n> > in a smooth way.\n> >\n> > This is our situation (simplified):\n> >\n> > [product1] [product2] ... (supermodules)\n> > / \\ / \\\n> > ... [foo] [os-abstraction-lib] [log-merger] ... (submodules)\n> >\n> >\n> > A developer does a modification to the os-abstraction-lib, and a\n> > modification to the log-merger that depends on the change in the\n> > os-abstraction-lib. He wants this into product2, and doesn't know or\n> > care about product1. He doesn't know whether his modification is\n> > acceptable or not, or whether his modification will go in before some\n> > other modification.\n> >\n> > He needs some way of pushing his modifications to a branch in the\n> > supermodule (e.g. \"change-131345\"), without interfering with anyone\n> > else. The problem is where to push the sub-modules, they need to be\n> > available for anyone who wants to get the \"change-131345\" branch of\n> > the product2, but the modifications shouldn't show up anywhere else\n> > (yet). Here are solutions we have thought of so far:\n>\n> The phrase \"without interfering with anyone else\" feels somewhat\n> wrong and I sense there is something missing in the description\n> of the workflow. When a developer pushes a change to somewhere\n> else, it must be because the change needs to be shared with\n> _somebody else_ (but not necessarily with _everybody_).\n>\n> Without knowing exactly what the desired workflow is, I'd hazard\n> a guess and would recommend something else, which is hopefully\n> a more useful way.\n>\n> When the developer makes that 131345 change in os-lib submodule,\n> he is acting as a developer of that library and advancing its\n> state. He wants to add an enhancement so that a particular way\n> to use it elsewhere (his use in log-merger program perhaps being\n> the first one of them) can be supported, but the change is not\n> accepted as the project wide one from os-lib project's point of\n> view. The change needs to be shared with people in product2\n> group that want to further work on top of the change he makes in\n> log-merger project, but not necessarily with everybody in\n> product2 group, let alone people in product1 group.\n>\n> That's exactly what a topic branch is about, isn't it?\n>\n> He has a topic to enhance something in os-lib project, so\n> whatever the mysterious 131345 can be made into one branch in\n> os-lib project and given a more meaningful topic name. He can\n> push that out to os-lib project, and bind its tip in his tree of\n> product2 superproject at os-lib directory, and push it to\n> produc2 repository (maybe to its 'master', or maybe also to its\n> one of the topic branches that houses his work-in-progress).\n>\n> That way, when somebody from product2 group needs to work on top\n> of the change he made and pushed out thusly updates, his copy of\n> os-lib will get the updates to (or perhaps creation of) the\n> topic branch that contains 131345 change, and he can start\n> working from where the original developer left off. He can even\n> fix bugs in the change in that 131345 topic in os-lib project\n> the original developer made, push that back, and the original\n> developer can build on top of that change.\n>\n>\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"64664","messageId":"20080107204922.GA19728@pvv.org","threadId":"11506","inReplyTo":"7vr6gtzaeq.fsf@gitster.siamese.dyndns.org","subject":"Re: RFC/RFH submodule handling in big setups","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2008-01-07T20:49:22Z","receivedAt":"2008-01-07T20:49:22Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Mon, Jan 07, 2008 at 11:46:21AM -0800, Junio C Hamano wrote:\n> Finn Arne Gangstad writes:\n> \n> > We're trying to get git to work well with our vision of submodules,\n> > and have to figure out how to make submodule fetching and pushing work\n> > in a smooth way.\n> >\n> > This is our situation (simplified):\n> >\n> > [product1] [product2] ... (supermodules)\n> > / \\ / \\\n> > ... [foo] [os-abstraction-lib] [log-merger] ... (submodules)\n> >\n> > [...]\n> \n> The phrase \"without interfering with anyone else\" feels somewhat\n> wrong and I sense there is something missing in the description\n> of the workflow. When a developer pushes a change to somewhere\n> else, it must be because the change needs to be shared with\n> _somebody else_ (but not necessarily with _everybody_).\n> \n> Without knowing exactly what the desired workflow is, I'd hazard\n> a guess and would recommend something else, which is hopefully\n> a more useful way.\n\nI'll try to explain a bit better, in different ways:\n\nWay 1: Think of product2 as a big repository\n\nI want to use git as if product2 was a single repository containing\nall its submodules as directories.\n\nI want to be able to send email patches agains product2 that affect\nany number of the submodules. I want to apply these in any order, and\nto let them live as topic branches in product2.\n\nWay 2: Changes to several submodules must be \"globally atomic\"\n\nIf I change submodule 1 and submodule 2, I want to be able to commit\nboth those changes as one atomic change in the supermodule - in a\ntopic branch. When merging that topic branch in the supermodule, both\nchanges in the submodules are merged. But NOT BEFORE. The submodules\ncannot be pre-merged (hence the need to push them \"somewhere\")\n\nWay 3: The submodules are not released on their own\n\nOnly the products are released, each product has different release\ncriteria, code freezes, whatever. Syncing of submodules between\nproducts happens rarely (a few times a year maybe). Modifications to\nsubmodules must fit each product's release criteria.\n\nThere is usually no one who is responsible for each submodule, they\nlive their life as part of the supermodule. Anyone can modify a\nsubmodule, but each product has a maintainer who decides what\nmodifications to the submodules are allowed in that product.\n\n\nDoes this make things clearer in any way?\n\n- Finn Arne\n"},{"id":"64665","messageId":"20080107205905.GB19728@pvv.org","threadId":"11506","inReplyTo":"20080107200756.GA20892@efreet.light.src","subject":"Re: RFC/RFH submodule handling in big setups","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2008-01-07T20:59:05Z","receivedAt":"2008-01-07T20:59:05Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Mon, Jan 07, 2008 at 09:07:56PM +0100, Jan Hudec wrote:\n> On Mon, Jan 07, 2008 at 11:23:27 +0100, Finn Arne Gangstad wrote:\n> > 3. each time you push a submodule, do a merge ours to a\n> > \"internal-submodule-tracking\" branch, and push to that. Something\n> > like this in other words:\n> > \n> > git fetch origin internal-submodule-tracking\n> > git merge -s ours origin/internal-submodule-tracking\n> > git push origin internal-submodule-tracking\n> > git reset --hard HEAD^1\n> > \n> > Issue: feels wrong somehow?\n> \n> Only one thing feels wrong here -- the merge -s ours. For one thing, the\n> commit is probably descendant of what was in the internal-submodule-tracking\n> branch (the branch name should actually have product2 in it's name).\n> If it is not, you should not artificially make it so, but rewind the branch.\n\nThe idea of the branch is to not have to make thousands of tags as\ntime passes, just to have a branch that refers to all the commits that\nthe supermodule refers to in the submodule.\n\nThe internal-submodule-tracking branch should look like this:\n\n / ... etc\n m\n / \\\n m o-commit 3 \n / \\\n m o-commit 2\n / \\\n . o-commit 1\n\nWhere all the \"m\" commits are just dummy merge commits, the contents\nare of no consequence (hence the \"merge -s ours\" that should always\nsilently go through). commit 1, 2 and 3, ... are the interesting ones,\nthey are the sha1s the supermodule refers to in the submodule. They\nmay or may not have any relationship to eachother. If they _do_ have\na realtionship to eachother, this will be tracked in some other branch\nin the submodule.\n\nSo the purpose of the internal-submodule-tracking branch is: Have a\nbranch to push to (you cannot just push a sha1 to nowhere), have\nsomething that refers to the sha1 so that it will not be pruned away,\nand have something that refers to the sha1 so it will actually be\n_fetched_ by git fetch.\n\n> But as Junio already told you, you should really manage the subproject like\n> a project (because it is a project), so the change should get to a topic\n> branch where the other superprojects can look at the change and decide\n> whether they want it or not.\n\nSee another mail I wote, I don't want to manage the subproject like a\nseparate project (it isn't).\n\n- Finn Arne\n"},{"id":"64669","messageId":"20080107210735.GC19728@pvv.org","threadId":"11506","inReplyTo":"320075ff0801071208u1900bf76q2f0dc9cb0dc4318b@mail.gmail.com","subject":"Re: RFC/RFH submodule handling in big setups","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2008-01-07T21:07:35Z","receivedAt":"2008-01-07T21:07:35Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Mon, Jan 07, 2008 at 08:08:38PM +0000, Nigel Magnay wrote:\n> Do you currently use svn?\n\nCurrently we use CVS. It hurts a bit.\n\n> This feels like the common technique of using svn:externals, where\n> product1 has\n> foo repo/foo/trunk\n> os-abstraction-lib repo/os-abstraction-lib/trunk\n> \n> product2 has\n> os-abstraction-lib repo/os-abstraction-lib/trunk\n> log-merger repos/log-merger/trunk\n> \n> Where git (if I understand submodules correctly) can't do the above,\n> because the links are to SHA1s rather than tags or names, so in svn\n> terms it'd be something like\n> os-abstraction-lib repo/os-abstraction-lib/trunk@xxx\n> log-merger repos/log-merger/trunk@yyy\n> \n> At first I thought the option (4) you suggest (Manually push all\n> sub-modules to some new branch before pushing the super-module) was\n> going to be a pain - but actually I came to the conclusion it was\n> actually better. In our svn world, commits to shared libraries (can)\n> cause all hell to break loose - it'd actually be an advantage to have\n> to promote changes into the supermodules (the products in our case).\n\nWith the way we envision using git, I don't think this is a\nproblem. Each supermodule decides what version of the shared library\nit wants to use, and since git does not point to tags/branches in\nsubmodules but to sha1s, there is nothing you can do to a submodule\nthat will cause any problems in a supermodule unless the supermodule\ndecides to use a new version.\n\nI think we'd be perfectly happy to use detached HEADs in all\nsubmodules, but there is no way to get that to work currently with\npush and fetch, so I'm looking for some alternative.\n\n- Finn Arne\n"},{"id":"64677","messageId":"7v4pdpz4mu.fsf@gitster.siamese.dyndns.org","threadId":"11506","inReplyTo":"20080107204922.GA19728@pvv.org","subject":"Re: RFC/RFH submodule handling in big setups","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-07T21:51:05Z","receivedAt":"2008-01-07T21:51:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Finn Arne Gangstad writes:\n\n> I'll try to explain a bit better, in different ways:\n>\n> Way 1: Think of product2 as a big repository\n>\n> I want to use git as if product2 was a single repository containing\n> all its submodules as directories.\n>\n> I want to be able to send email patches agains product2 that affect\n> any number of the submodules. I want to apply these in any order, and\n> to let them live as topic branches in product2.\n>\n> Way 2: Changes to several submodules must be \"globally atomic\"\n>\n> If I change submodule 1 and submodule 2, I want to be able to commit\n> both those changes as one atomic change in the supermodule - in a\n> topic branch. When merging that topic branch in the supermodule, both\n> changes in the submodules are merged. But NOT BEFORE. The submodules\n> cannot be pre-merged (hence the need to push them \"somewhere\")\n>\n> Way 3: The submodules are not released on their own\n>\n> Only the products are released, each product has different release\n> criteria, code freezes, whatever. Syncing of submodules between\n> products happens rarely (a few times a year maybe). Modifications to\n> submodules must fit each product's release criteria.\n>\n> There is usually no one who is responsible for each submodule, they\n> live their life as part of the supermodule. Anyone can modify a\n> submodule, but each product has a maintainer who decides what\n> modifications to the submodules are allowed in that product.\n>\n> Does this make things clearer in any way?\n\nYes, I think my guess was not too far off the mark.\n\nTo achieve #1, when you create a topic for product2, you can\ncreate a corresponding topic in its submodules. Because os-lib\nis shared between product1 and product2 groups, you may want to\nhave a namespace rule agreed upon between the groups involved.\nIt could be something as simple as \"in os-lib, topics from\nproduct2 group are named with product2/ prefix\".\n\nThen a topic to add a fancy coloring to log-merger program in\nproduct2 can be called \"fancy-color\". When you create that\ntopic branch, you also create product2/fancy-color in os-lib\nsubmodule and switch both to it (currently there is no\nsingle-step Porcelain for this, so you would do something like\n\"git checkout -b fancy-color; cd os-lib; git checkout -b\nproduct2/fancy-color; cd ..\". There is a beginning of\ndiscussion regarding recursive git-submodule behaviour, which\nwould be a good place to polich the idea further). The topic\nbranch product2/fancy-color in os-lib project would be the one\nI discussed in my previous message. That can be pushed out\nfirst if it needs further futzing by people other than the\noriginal developer.\n\nI am not sure if you are stating what you really want correctly\nabout #2. git submodule is designed to be usable as a\nstandalone project. A commit in a submodule is an atomic event\nin that submodule. Another commit that updates the containing\nproject to point at that commit in the submodule will be the\natomic event that updates both the containing project and the\ncontained submodule at the same time from the containing\nproject's point of view, in the sense that before that commit\nthe containing project does not see that change in the\nsubmodule, and after that commit it does.\n\nSo a possible workflow would be:\n\n - The original developer creates fancy-color topic in product2\n and product2/fancy-color topic in os-lib and log-merge;\n\n - He hacks away, creates commits to advance the topic branches\n in the submodules involved and at the toplevel project as he\n sees fit;\n\n - He pushes out product2/fancy-color topic of os-lib project.\n This can be done even before pushing out the toplevel or\n log-merge project if your process requires for managers of\n product2 group to approve and update the change to os-lib\n project made by the group (that is, topic branches under\n product2/ namespace).\n\n - If the manager updated product2/fancy-color topic in os-lib,\n the original developer can pull to update his copy of os-lib,\n update his copy of the toplevel product2 project and commit\n the integration results. In his repository, that commit in\n the toplevel is the single atomic event that finishes the\n fancy-color topic (eh, the initial round of it, anyway). \n\n - That toplevel commit to fancy-color topic is pushed out. The\n appearance of that commit could be the single atomic event\n that makes the fancy-color topic global. Alternatively,\n merging that whole topic (both \"fancy-color\" in the toplevel\n and \"product2/fancy-color\" in submodules) to the mainline\n branch of the product2 group (perhaps that branch is called\n 'master' in the product2 project and 'product2/master' in\n os-lib project) could be the single atomic event that makes\n the changes \"official\", from product2 group's point of view.\n\nI do not think #3 matters in the discussion at all. If os-lib\ndoes not get released, that's your code and that's your choice.\nIt does not change the project and history management aspect of\nanything.\n\nAlthough it is unclear how you plan to avoid reinventing\npotentially conflicting wheels across groups without _any_\ncoordination, once your product groups start to have diverging\nneeds, but if your product groups never talk with each other and\nnever share their improvements and enhancements to the shared\npart of the codebase, that's also your choice. It does not\nchange the history management aspect of anything.\n"}]}