Re: how to work in hirarchical git model?

From: Gili Pearl <gili.pearl@yahoo.com>
Date: Dec 17, 2008, 08:23 UTC
Message-ID: <753177.33978.qm@web112212.mail.gq1.yahoo.com>
In-Reply-To: <4948AB14.8030004@viscovery.net>

----- Original Message ----

Show 22 quoted lines

> From: Johannes Sixt <j.sixt@viscovery.net>
> 
> Gili Pearl schrieb:
> > Here is one problem I saw when trying to work in the three-level model.
> > At some point, I had the following setup:
> > 
> > top-level : A----B----C----D
> >                  \
> >                    \
> > mid-level1:        K----L----M
> >                          \
> >                            \
> > low-level1:                X----Y
> > 
> > The maintainer of mid-level1 has decided that commits K L M are ready to be 
> > merged into the top-level repo. So he rebased on top-level before asking 'please 
> > pull', but after that the low-level was not able to rebase on the mid-level 
> > any more. 
> 
> In this model, the mid-level1 maintainer should *not* rebase against
> top-level. Rather, he should ask the top-level maintainer to *merge* K-L-M.
>

But what if K-L-M conflict with C-D? The one who should take care about it is the mid-level1 maintainer (or possibly one of the low-level1 maintainers).

Show 5 quoted lines

> > So what is the right working flow for us?
> 
> The only ones who should be allowed to rebase are developers at the lowest
> level. Everyone else should only pull or merge.
>

I still don't see clearly what happens next in the example above when the low level developr wants to push X-Y upstream? On which branch should he rebase? Need he rebase on mid-level (where K-L-M were already merged upstream), or maybe direclty on the top-level??

Thanks