git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: how to work in hirarchical git model?

From
GPGili Pearl <gili.pearl@yahoo.com>
Date
Dec 17, 2008, 08:44 UTC
Message-ID
<892158.12966.qm@web112209.mail.gq1.yahoo.com>
In-Reply-To
<200812170933.04080.johan@herland.net>

Johan, Johanes, Thanks! You made yourself prefectly clear. git is wonderfult :)

----- Original Message ----
Show 64 quoted lines
> From: Johan Herland <johan@herland.net>
> 
> On Wednesday 17 December 2008, Gili Pearl wrote:
> > ----- Original Message ----
> >
> > > From: Johannes Sixt 
> > > 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, 
> www.herland.net
Previous: Johan HerlandNext: Gili Pearl
Message 5 of 8 in “how to work in hirarchical git model?”
  1. Gili PearlDec 16, 2008
  2. Johannes SixtDec 17, 2008
  3. Gili PearlDec 17, 2008
  4. Johan HerlandDec 17, 2008
  5. Gili PearlDec 17, 2008
  6. Gili PearlDec 17, 2008
  7. Johan HerlandDec 18, 2008
  8. Johannes SixtDec 17, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.