From: Johan Herland <johan@herland.net>
To: git@vger.kernel.org
Cc: Gili Pearl <gili.pearl@yahoo.com>, Johannes Sixt <j.sixt@viscovery.net>
Subject: Re: how to work in hirarchical git model?
Date: Wed, 17 Dec 2008 09:33:03 +0100 [thread overview]
Message-ID: <200812170933.04080.johan@herland.net> (raw)
In-Reply-To: <753177.33978.qm@web112212.mail.gq1.yahoo.com>
On Wednesday 17 December 2008, Gili Pearl wrote:
> ----- 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).
If there is a merge conflict, mid-level1 maintainer will typically merge D
and M into a new merge commit N:
top-level : A----B----C----D
\ \
\ \
mid-level1: K----L----M----N
...and then ask top-level maintainer to merge N (which should have no
conflicts by now). The merge can also be done by low-level1 developer.
> > > So what is the right working flow for us?
> >
> > The only ones who should be allowed to rebase are developers at the
> > lowest level. Everyone else should only pull or merge.
>
> 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??
If you're a leaf developer (i.e. allowed to rebase), you should rebase
against your immediate upstream's branch. In this example, that is
mid-level1's branch.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
next prev parent reply other threads:[~2008-12-17 8:35 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 [this message]
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
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=200812170933.04080.johan@herland.net \
--to=johan@herland.net \
--cc=gili.pearl@yahoo.com \
--cc=git@vger.kernel.org \
--cc=j.sixt@viscovery.net \
/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).