From: Johannes Sixt <j.sixt@viscovery.net>
To: Gili Pearl <gili.pearl@yahoo.com>
Cc: git@vger.kernel.org
Subject: Re: how to work in hirarchical git model?
Date: Wed, 17 Dec 2008 09:48:36 +0100 [thread overview]
Message-ID: <4948BCE4.7030605@viscovery.net> (raw)
In-Reply-To: <753177.33978.qm@web112212.mail.gq1.yahoo.com>
Gili Pearl schrieb:
> ----- 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
prev parent reply other threads:[~2008-12-17 8:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-16 22:26 how to work in hirarchical git model? Gili Pearl
2008-12-17 7:32 ` Johannes Sixt
2008-12-17 8:23 ` Gili Pearl
2008-12-17 8:33 ` Johan Herland
2008-12-17 8:44 ` Gili Pearl
2008-12-17 22:59 ` Gili Pearl
2008-12-18 1:00 ` Johan Herland
2008-12-17 8:48 ` Johannes Sixt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4948BCE4.7030605@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=gili.pearl@yahoo.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).