----- Original Message ----
> From: Johannes Sixt <j.sixt@xxxxxxxxxxxxx>
>
> 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).
> > 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
--
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
