On Wednesday 17 December 2008, Gili Pearl wrote:
> > From: Johan Herland <johan@xxxxxxxxxxx>
> > 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@xxxxxxxxxxx>
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
