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