{"thread":{"id":"16756","subject":"how to work in hirarchical git model?","startedAt":"2008-12-16T22:26:56Z","lastAt":"2008-12-18T01:00:57Z","messageCount":8,"participants":["Gili Pearl","Johannes Sixt","Johan Herland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"98083","messageId":"703400.93370.qm@web112210.mail.gq1.yahoo.com","threadId":"16756","inReplyTo":null,"subject":"how to work in hirarchical git model?","fromName":"Gili Pearl","fromEmail":"gili.pearl@yahoo.com","sentAt":"2008-12-16T22:26:56Z","receivedAt":"2008-12-16T22:26:56Z","isPatch":false,"sender":{"key":"gili.pearl@yahoo.com","avatar":null},"body":"[Not sure I'm posting to the right mailing list; sorry in advance]\n\nI’m working in a small company with about 15 developers. So far we were all \nrebasing our local repos on a single main repo. When one had some new commits, \nhe rebased them on the main-repo/master and asked the main-repo maintainer to \npull them in. So far so good, but we now considering moving into a three level \nmodel, where we’ll have sub-maintainers that will handle local merges before \nthey hit the main-repo. I’m not sure I understand how this is supposed to work \nand I’d be thankful to get some advice. \n\nHere is one problem I saw when trying to work in the three-level model.\nAt some point, I had the following setup:\n\ntop-level : A----B----C----D\n                  \\\n                   \\\nmid-level1:         K----L----M\n                          \\\n                           \\\nlow-level1:                 X----Y\n\nThe maintainer of mid-level1 has decided that commits K L M are ready to be \nmerged into the top-level repo. So he rebased on top-level before asking 'please \npull', but after that the low-level was not able to rebase on the mid-level \nany more. \nI can understand that the problem is because commit L had become L', and now \nlow-level1 cannot find L anymore, i.e. now it looks like this:\n\ntop-level : A----B----C----D\n                            \\\n                             \\\nmid-level1:                   K'----L'----M'\n                          \\\n                           \\\nlow-level1:                 X----Y\n\n... but I guess this is not how it should work. So what is the right working \nflow for us?\n\nThanks.\n\n\n \n"},{"id":"98100","messageId":"4948AB14.8030004@viscovery.net","threadId":"16756","inReplyTo":"703400.93370.qm@web112210.mail.gq1.yahoo.com","subject":"Re: how to work in hirarchical git model?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-12-17T07:32:36Z","receivedAt":"2008-12-17T07:32:36Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Gili Pearl schrieb:\n> Here is one problem I saw when trying to work in the three-level model.\n> At some point, I had the following setup:\n> \n> top-level : A----B----C----D\n> \\\n> \\\n> mid-level1: K----L----M\n> \\\n> \\\n> low-level1: X----Y\n> \n> The maintainer of mid-level1 has decided that commits K L M are ready to be \n> merged into the top-level repo. So he rebased on top-level before asking 'please \n> pull', but after that the low-level was not able to rebase on the mid-level \n> any more. \n\nIn this model, the mid-level1 maintainer should *not* rebase against\ntop-level. Rather, he should ask the top-level maintainer to *merge* K-L-M.\n\n> So what is the right working flow for us?\n\nThe only ones who should be allowed to rebase are developers at the lowest\nlevel. Everyone else should only pull or merge.\n\n-- Hannes\n"},{"id":"98108","messageId":"753177.33978.qm@web112212.mail.gq1.yahoo.com","threadId":"16756","inReplyTo":"4948AB14.8030004@viscovery.net","subject":"Re: how to work in hirarchical git model?","fromName":"Gili Pearl","fromEmail":"gili.pearl@yahoo.com","sentAt":"2008-12-17T08:23:05Z","receivedAt":"2008-12-17T08:23:05Z","isPatch":false,"sender":{"key":"gili.pearl@yahoo.com","avatar":null},"body":"----- Original Message ----\n> From: Johannes Sixt \n> \n> Gili Pearl schrieb:\n> > Here is one problem I saw when trying to work in the three-level model.\n> > At some point, I had the following setup:\n> > \n> > top-level : A----B----C----D\n> >                  \\\n> >                    \\\n> > mid-level1:        K----L----M\n> >                          \\\n> >                            \\\n> > low-level1:                X----Y\n> > \n> > The maintainer of mid-level1 has decided that commits K L M are ready to be \n> > merged into the top-level repo. So he rebased on top-level before asking 'please \n> > pull', but after that the low-level was not able to rebase on the mid-level \n> > any more. \n> \n> In this model, the mid-level1 maintainer should *not* rebase against\n> top-level. Rather, he should ask the top-level maintainer to *merge* K-L-M.\n> \n\n\nBut what if K-L-M conflict with C-D? The one who should take care about it is \nthe mid-level1 maintainer (or possibly one of the low-level1 maintainers).\n\n> > So what is the right working flow for us?\n> \n> The only ones who should be allowed to rebase are developers at the lowest\n> level. Everyone else should only pull or merge.\n> \n\nI still don't see clearly what happens next in the example above when the low \nlevel developr wants to push X-Y upstream? On which branch should he rebase? \nNeed he rebase on mid-level (where K-L-M were already merged upstream), or \nmaybe direclty on the top-level?? \n\nThanks\n\n\n\n \n"},{"id":"98109","messageId":"200812170933.04080.johan@herland.net","threadId":"16756","inReplyTo":"753177.33978.qm@web112212.mail.gq1.yahoo.com","subject":"Re: how to work in hirarchical git model?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-12-17T08:33:03Z","receivedAt":"2008-12-17T08:33:03Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 17 December 2008, Gili Pearl wrote:\n> ----- Original Message ----\n>\n> > From: Johannes Sixt \n> > Gili Pearl schrieb:\n> > > Here is one problem I saw when trying to work in the three-level\n> > > model. At some point, I had the following setup:\n> > >\n> > > top-level : A----B----C----D\n> > >                  \\\n> > >                    \\\n> > > mid-level1:        K----L----M\n> > >                          \\\n> > >                            \\\n> > > low-level1:                X----Y\n> > >\n> > > The maintainer of mid-level1 has decided that commits K L M are ready\n> > > to be merged into the top-level repo. So he rebased on top-level\n> > > before asking 'please pull', but after that the low-level was not\n> > > able to rebase on the mid-level any more.\n> >\n> > In this model, the mid-level1 maintainer should *not* rebase against\n> > top-level. Rather, he should ask the top-level maintainer to *merge*\n> > K-L-M.\n>\n> But what if K-L-M conflict with C-D? The one who should take care about\n> it is  the mid-level1 maintainer (or possibly one of the low-level1\n> maintainers).\n\nIf there is a merge conflict, mid-level1 maintainer will typically merge D \nand M into a new merge commit N:\n\n top-level : A----B----C----D\n \\ \\\n \\ \\\n mid-level1: K----L----M----N\n\n...and then ask top-level maintainer to merge N (which should have no \nconflicts by now). The merge can also be done by low-level1 developer.\n\n> > > So what is the right working flow for us?\n> >\n> > The only ones who should be allowed to rebase are developers at the\n> > lowest level. Everyone else should only pull or merge.\n>\n> I still don't see clearly what happens next in the example above when the\n> low level developr wants to push X-Y upstream? On which branch should he\n> rebase? Need he rebase on mid-level (where K-L-M were already\n> merged upstream), or maybe direclty on the top-level??\n\nIf you're a leaf developer (i.e. allowed to rebase), you should rebase \nagainst your immediate upstream's branch. In this example, that is \nmid-level1's branch.\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"98112","messageId":"892158.12966.qm@web112209.mail.gq1.yahoo.com","threadId":"16756","inReplyTo":"200812170933.04080.johan@herland.net","subject":"Re: how to work in hirarchical git model?","fromName":"Gili Pearl","fromEmail":"gili.pearl@yahoo.com","sentAt":"2008-12-17T08:44:34Z","receivedAt":"2008-12-17T08:44:34Z","isPatch":false,"sender":{"key":"gili.pearl@yahoo.com","avatar":null},"body":"Johan, Johanes, Thanks! You made yourself prefectly clear.\ngit is wonderfult :)\n\n\n----- Original Message ----\n> From: Johan Herland \n> \n> On Wednesday 17 December 2008, Gili Pearl wrote:\n> > ----- Original Message ----\n> >\n> > > From: Johannes Sixt \n> > > Gili Pearl schrieb:\n> > > > Here is one problem I saw when trying to work in the three-level\n> > > > model. At some point, I had the following setup:\n> > > >\n> > > > top-level : A----B----C----D\n> > > >                  \\\n> > > >                    \\\n> > > > mid-level1:        K----L----M\n> > > >                          \\\n> > > >                            \\\n> > > > low-level1:                X----Y\n> > > >\n> > > > The maintainer of mid-level1 has decided that commits K L M are ready\n> > > > to be merged into the top-level repo. So he rebased on top-level\n> > > > before asking 'please pull', but after that the low-level was not\n> > > > able to rebase on the mid-level any more.\n> > >\n> > > In this model, the mid-level1 maintainer should *not* rebase against\n> > > top-level. Rather, he should ask the top-level maintainer to *merge*\n> > > K-L-M.\n> >\n> > But what if K-L-M conflict with C-D? The one who should take care about\n> > it is  the mid-level1 maintainer (or possibly one of the low-level1\n> > maintainers).\n> \n> If there is a merge conflict, mid-level1 maintainer will typically merge D \n> and M into a new merge commit N:\n> \n> top-level : A----B----C----D\n>               \\              \\\n>                 \\              \\\n> mid-level1:    K----L----M----N\n> \n> ...and then ask top-level maintainer to merge N (which should have no \n> conflicts by now). The merge can also be done by low-level1 developer.\n> \n> > > > So what is the right working flow for us?\n> > >\n> > > The only ones who should be allowed to rebase are developers at the\n> > > lowest level. Everyone else should only pull or merge.\n> >\n> > I still don't see clearly what happens next in the example above when the\n> > low level developr wants to push X-Y upstream? On which branch should he\n> > rebase? Need he rebase on mid-level (where K-L-M were already\n> > merged upstream), or maybe direclty on the top-level??\n> \n> If you're a leaf developer (i.e. allowed to rebase), you should rebase \n> against your immediate upstream's branch. In this example, that is \n> mid-level1's branch.\n> \n> \n> Have fun!\n> \n> ...Johan\n> \n> -- \n> Johan Herland, \n> www.herland.net\n\n\n\n \n"},{"id":"98113","messageId":"4948BCE4.7030605@viscovery.net","threadId":"16756","inReplyTo":"753177.33978.qm@web112212.mail.gq1.yahoo.com","subject":"Re: how to work in hirarchical git model?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-12-17T08:48:36Z","receivedAt":"2008-12-17T08:48:36Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Gili Pearl schrieb:\n> ----- Original Message ----\n>> From: Johannes Sixt \n>>\n>> Gili Pearl schrieb:\n>>> Here is one problem I saw when trying to work in the three-level model.\n>>> At some point, I had the following setup:\n>>>\n>>> top-level : A----B----C----D\n>>> \\\n>>> \\\n>>> mid-level1: K----L----M\n>>> \\\n>>> \\\n>>> low-level1: X----Y\n>>>\n>>> The maintainer of mid-level1 has decided that commits K L M are ready to be \n>>> merged into the top-level repo. So he rebased on top-level before asking 'please \n>>> pull', but after that the low-level was not able to rebase on the mid-level \n>>> any more. \n>> In this model, the mid-level1 maintainer should *not* rebase against\n>> top-level. Rather, he should ask the top-level maintainer to *merge* K-L-M.\n>>\n> \n> \n> But what if K-L-M conflict with C-D? The one who should take care about it is \n> the mid-level1 maintainer (or possibly one of the low-level1 maintainers).\n\nIdeally, mid-level1 maintainer will have done the merge in a throw-away\nbranch and will know about the difficulties of the merge and has to tell\ntop-level maintainer about it. Then top-level maintainer decides whether\nhe can redo the merge himself (because it's trivial enough), or whether he\nprefers to pull the throw-away merge, which then obviously is\nnot-so-throw-away anymore.\n\n> I still don't see clearly what happens next in the example above when the low \n> level developr wants to push X-Y upstream? On which branch should he rebase? \n> Need he rebase on mid-level (where K-L-M were already merged upstream), or \n> maybe direclty on the top-level?? \n\nThe question is perhaps: How do the mid-level and low-level developers get\nthe changes made by the other teams?\n\nThe answer is: When mid-level has completed a feature (i.e. the branch was\nintegrated into top-level), then he is allowed to pull from top-level.\nThis must result in a fast-forward merge. Low-level developers always\nrebase against mid-level.\n\n-- Hannes\n"},{"id":"98201","messageId":"897592.56642.qm@web112219.mail.gq1.yahoo.com","threadId":"16756","inReplyTo":"200812170933.04080.johan@herland.net","subject":"Re: how to work in hirarchical git model?","fromName":"Gili Pearl","fromEmail":"gili.pearl@yahoo.com","sentAt":"2008-12-17T22:59:38Z","receivedAt":"2008-12-17T22:59:38Z","isPatch":false,"sender":{"key":"gili.pearl@yahoo.com","avatar":null},"body":"> From: Johan Herland \n> \n> On Wednesday 17 December 2008, Gili Pearl wrote:\n> > ----- Original Message ----\n> >\n> > > From: Johannes Sixt \n> > > Gili Pearl schrieb:\n> > > > Here is one problem I saw when trying to work in the three-level\n> > > > model. At some point, I had the following setup:\n> > > >\n> > > > top-level : A----B----C----D\n> > > >                  \\\n> > > >                    \\\n> > > > mid-level1:        K----L----M\n> > > >                          \\\n> > > >                            \\\n> > > > low-level1:                X----Y\n> > > >\n> > > > The maintainer of mid-level1 has decided that commits K L M are ready\n> > > > to be merged into the top-level repo. So he rebased on top-level\n> > > > before asking 'please pull', but after that the low-level was not\n> > > > able to rebase on the mid-level any more.\n> > >\n> > > In this model, the mid-level1 maintainer should *not* rebase against\n> > > top-level. Rather, he should ask the top-level maintainer to *merge*\n> > > K-L-M.\n> >\n> > But what if K-L-M conflict with C-D? The one who should take care about\n> > it is  the mid-level1 maintainer (or possibly one of the low-level1\n> > maintainers).\n> \n> If there is a merge conflict, mid-level1 maintainer will typically merge D \n> and M into a new merge commit N:\n> \n> top-level : A----B----C----D\n>               \\              \\\n>                 \\              \\\n> mid-level1:    K----L----M----N\n> \n\nThere's one thing that still bothers me and I'd like to understand. \nWhat if someone looks both on top-level repo and mid-level1 repo, and he \nwant to diff some local commit X against commit D. I didn't try it, but I \nwonder how git knows against which D to compare? On the top-level D means \nA-B-C-D while on the mid-level1 C means A-K-L-M-B-C-D (that is what git-log \non mid-level shows). I'm probably missing something here... commit id \ncannot represent two different histories, right?\n\n> ...and then ask top-level maintainer to merge N (which should have no \n> conflicts by now). The merge can also be done by low-level1 developer.\n> \n\n\nHow can it be done by low-level1? you mean by bypassing mid-level and merging \ntop-level directly?\n\n\n\n \n"},{"id":"98209","messageId":"200812180200.57847.johan@herland.net","threadId":"16756","inReplyTo":"897592.56642.qm@web112219.mail.gq1.yahoo.com","subject":"Re: how to work in hirarchical git model?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-12-18T01:00:57Z","receivedAt":"2008-12-18T01:00:57Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 17 December 2008, Gili Pearl wrote:\n> > From: Johan Herland \n> > On Wednesday 17 December 2008, Gili Pearl wrote:\n> > > But what if K-L-M conflict with C-D? The one who should take care\n> > > about it is  the mid-level1 maintainer (or possibly one of the\n> > > low-level1 maintainers).\n> >\n> > If there is a merge conflict, mid-level1 maintainer will typically\n> > merge D and M into a new merge commit N:\n> >\n> > top-level : A----B----C----D\n> >             \\              \\\n> >               \\              \\\n> > mid-level1:    K----L----M----N\n>\n> There's one thing that still bothers me and I'd like to understand.\n> What if someone looks both on top-level repo and mid-level1 repo, and he\n> want to diff some local commit X against commit D. I didn't try it, but I\n> wonder how git knows against which D to compare? On the top-level D means\n> A-B-C-D while on the mid-level1 C means A-K-L-M-B-C-D (that is what\n> git-log on mid-level shows). I'm probably missing something here...\n> commit id cannot represent two different histories, right?\n\nD will always be the same commit in both top-level repo and mid-level1 repo. \nRemember that D precedes the merge commit N, so D is not changed by the \nmerge at all (then we could no longer call it D).\n\nThe diagram above is slightly misleading, in that it does not say whether \nthe merge commit N has been pulled into the top-level repo or not. Here are \nmore descriptive illustrations:\n\nA) Before the merge:\n\n A----B----C----D <-- top-level\n \\\n \\\n K----L----M <-- mid-level1\n\nB) After mid-level1 has done the merge\n\n A----B----C----D <-- top-level\n \\ \\\n \\ \\\n K----L----M----N <-- mid-level1\n\nC) After top-level has pulled the merge from mid-level1 (assuming top-level \nhas done nothing in the meantime, and can fast-forward to N)\n\n A----B----C----D\n \\ \\\n \\ \\\n K----L----M----N <-- mid-level1 & top-level\n\n> > ...and then ask top-level maintainer to merge N (which should have no\n> > conflicts by now). The merge can also be done by low-level1 developer.\n>\n> How can it be done by low-level1? you mean by bypassing mid-level and\n> merging top-level directly?\n\nNo. low-level1 will do the merge commit in his repo (typically by creating a \nnew branch at M (thus keeping X & Y out of the way), and then merging D \ninto this new branch to produce N), and will then ask mid-level1 to pull \nthe merge into her repo. From there, the situation is similar to the above \ndiagrams.\n\nIn principle, it's possible for low-level1 to ask top-level directly to pull \nhis merge commit, but this is probably frowned upon, because it breaks the \nproject conventions (although git itself has no problem with this).\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"}]}