Re: how to work in hirarchical git model?

From: Johan Herland <redacted>

On Wednesday 17 December 2008, Gili Pearl wrote:

quoted

----- Original Message ----

quoted

From: Johannes Sixt 
Gili Pearl schrieb:

quoted

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?