how to work in hirarchical git model?

how to work in hirarchical git model?

[Gili Pearl]

[Not sure I'm posting to the right mailing list; sorry in advance]

I’m working in a small company with about 15 developers. So far we were all 
rebasing our local repos on a single main repo. When one had some new commits, 
he rebased them on the main-repo/master and asked the main-repo maintainer to 
pull them in. So far so good, but we now considering moving into a three level 
model, where we’ll have sub-maintainers that will handle local merges before 
they hit the main-repo. I’m not sure I understand how this is supposed to work 
and I’d be thankful to get some advice. 

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. 
I can understand that the problem is because commit L had become L', and now 
low-level1 cannot find L anymore, i.e. now it looks like this:

top-level : A----B----C----D
                            \
                             \
mid-level1:                   K'----L'----M'
                          \
                           \
low-level1:                 X----Y

... but I guess this is not how it should work. So what is the right working 
flow for us?

Thanks.


      

Re: how to work in hirarchical git model?

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

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

-- Hannes

Re: how to work in hirarchical git model?

[Gili Pearl]

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

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

Thanks



      

Re: how to work in hirarchical git model?

[Johan Herland]

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

Re: how to work in hirarchical git model?

[Gili Pearl]

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


----- Original Message ----
> 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



      

Re: how to work in hirarchical git model?

[Johannes Sixt]

Gili Pearl schrieb:
> ----- 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).

Ideally, mid-level1 maintainer will have done the merge in a throw-away
branch and will know about the difficulties of the merge and has to tell
top-level maintainer about it. Then top-level maintainer decides whether
he can redo the merge himself (because it's trivial enough), or whether he
prefers to pull the throw-away merge, which then obviously is
not-so-throw-away anymore.

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

The question is perhaps: How do the mid-level and low-level developers get
the changes made by the other teams?

The answer is: When mid-level has completed a feature (i.e. the branch was
integrated into top-level), then he is allowed to pull from top-level.
This must result in a fast-forward merge. Low-level developers always
rebase against mid-level.

-- Hannes

Re: how to work in hirarchical git model?

[Gili Pearl]

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



      

Re: how to work in hirarchical git model?

[Johan Herland]

On Wednesday 17 December 2008, Gili Pearl wrote:
> > From: Johan Herland <johan@herland.net>
> > On Wednesday 17 December 2008, Gili Pearl wrote:
> > > 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?

D will always be the same commit in both top-level repo and mid-level1 repo. 
Remember that D precedes the merge commit N, so D is not changed by the 
merge at all (then we could no longer call it D).

The diagram above is slightly misleading, in that it does not say whether 
the merge commit N has been pulled into the top-level repo or not. Here are 
more descriptive illustrations:

A) Before the merge:

  A----B----C----D    <-- top-level
   \
    \
     K----L----M    <-- mid-level1

B) After mid-level1 has done the merge

  A----B----C----D    <-- top-level
   \              \
    \              \
     K----L----M----N    <-- mid-level1

C) After top-level has pulled the merge from mid-level1 (assuming top-level 
has done nothing in the meantime, and can fast-forward to N)

  A----B----C----D
   \              \
    \              \
     K----L----M----N    <-- mid-level1 & top-level

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

No. low-level1 will do the merge commit in his repo (typically by creating a 
new branch at M (thus keeping X & Y out of the way), and then merging D 
into this new branch to produce N), and will then ask mid-level1 to pull 
the merge into her repo. From there, the situation is similar to the above 
diagrams.

In principle, it's possible for low-level1 to ask top-level directly to pull 
his merge commit, but this is probably frowned upon, because it breaks the 
project conventions (although git itself has no problem with this).


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net