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.
From: Johannes Sixt <hidden> Date: 2016-06-15 22:45:47
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
From: Gili Pearl <hidden> Date: 2016-06-15 22:45:47
----- Original Message ----
From: Johannes Sixt <redacted>
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).
quoted
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
From: Johan Herland <hidden> Date: 2016-06-15 22:45:47
On Wednesday 17 December 2008, Gili Pearl wrote:
----- Original Message ----
quoted
From: Johannes Sixt <redacted>
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
...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.
quoted
quoted
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, [off-list ref]
www.herland.net
From: Gili Pearl <hidden> Date: 2016-06-15 22:45:47
Johan, Johanes, Thanks! You made yourself prefectly clear.
git is wonderfult :)
----- Original Message ----
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
...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.
quoted
quoted
quoted
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
From: Johannes Sixt <hidden> Date: 2016-06-15 22:45:47
Gili Pearl schrieb:
----- Original Message ----
quoted
From: Johannes Sixt <redacted>
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).
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
From: Gili Pearl <hidden> Date: 2016-06-15 22:45:47
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?
From: Johan Herland <hidden> Date: 2016-06-15 22:45:47
On Wednesday 17 December 2008, Gili Pearl wrote:
quoted
From: Johan Herland <redacted>
On Wednesday 17 December 2008, Gili Pearl wrote:
quoted
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
quoted
...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, [off-list ref]
www.herland.net