git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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