Gili Pearl schrieb: > ----- 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). Ideally, mid-level1 maintainer will have done the merge in a throw-away branch and will know about the difficulties of the merge and has to tell top-level maintainer about it. Then top-level maintainer decides whether he can redo the merge himself (because it's trivial enough), or whether he prefers to pull the throw-away merge, which then obviously is not-so-throw-away anymore. > 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?? The question is perhaps: How do the mid-level and low-level developers get the changes made by the other teams? The answer is: When mid-level has completed a feature (i.e. the branch was integrated into top-level), then he is allowed to pull from top-level. This must result in a fast-forward merge. Low-level developers always rebase against mid-level. -- Hannes -- 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
