Re: how to work in hirarchical git model?

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Dec 17, 2008, 08:48 UTC
Message-ID: <4948BCE4.7030605@viscovery.net>
In-Reply-To: <753177.33978.qm@web112212.mail.gq1.yahoo.com>

Gili Pearl schrieb:

Show 26 quoted lines

> ----- Original Message ----
>> 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).

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