Re: how to work in hirarchical git model?

From: Gili Pearl <gili.pearl@yahoo.com>
Date: Dec 17, 2008, 22:59 UTC
Message-ID: <897592.56642.qm@web112219.mail.gq1.yahoo.com>
In-Reply-To: <200812170933.04080.johan@herland.net>

Show 39 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
>

There's one thing that still bothers me and I'd like to understand. What if someone looks both on top-level repo and mid-level1 repo, and he want to diff some local commit X against commit D. I didn't try it, but I wonder how git knows against which D to compare? On the top-level D means A-B-C-D while on the mid-level1 C means A-K-L-M-B-C-D (that is what git-log on mid-level shows). I'm probably missing something here... commit id cannot represent two different histories, right?

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

How can it be done by low-level1? you mean by bypassing mid-level and merging top-level directly?