All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.