Thread (8 messages) 8 messages, 3 authors, 2016-06-15

how to work in hirarchical git model?

flat view

From: Gili Pearl <hidden>
Date: 2016-06-15 22:45:47

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


      
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help