Martin Pool mbp at
Thu Jun 30 04:09:03 BST 2005

On 29 Jun 2005, John A Meinel <john at> wrote:

> Actually, I'm talking about an exact patch. If cset.base_id ==
> branch.last_patch() then it should be completely possible to add the
> revision as just the next entry in revision-history. Think pull as
> opposed to merge.

I think you just made the same mistake I did: :-) the base of the
changeset (left hand side of the diffs) is not necessarily the parent of
the changeset revision.

If one of the *parents* of the changeset is the head of the recipient's
history then the changeset can become the next entry of the history.

I think this works well: I go to sleep (and stop committing), and John
creates a series of revisions from my head revision; in the morning I
can pull them straight onto mainline.

This looks like

Martin A - B - C           G - H - I
                \         /         \
John             D - E - F           J - K - L ...

So the nice thing is that as long as there is no actual divergence,
there need not be any merging.

Extending this, perhaps I do some commits before I merge last thing
in the afternoon:

Martin A - B - C --------- G - H - I
                \                 / \
John             D - E - F--------   J - K - L ...

> Otherwise if base is in the working trees ancestry, it gets added as a
> 'merged-revision' and a new commit needs to be created, with it as one
> of the parents.


> The other interesting trick with merging another persons tree is the
> following:
> Me-  A - B - C
> #    |     \   \
> You- + - D - E - F
> According to my understanding of what Martin has said, it should be
> possible that F is simply a 'pull' of C. Because C's ancestor is in the
> list of parents for E.

Not quite: that would lose the information in E because it hasn't
been merged into C.   However, once You has done the merge in F, Me can
simply pull that back, accepting You's reconciliation of the two branches:

 Me-  A - B - C     *
 #    |     \   \  /
 You- + - D - E - F

F can be pulled into the space * because it has merged C (and by
extension all the other work on Alex's line).

So the rule is we can do a pull rather than a merge when the revision to
be pulled has merged everything already on this branch, which means
nothing needs to be merged.

> Another interesting possibility is that if you are merging a line of
> development like this:
> Me-  A - B - C
> #    |         \
> You- + - D - - - E
> In theory, you can do another way:
> Me-  A - B - C
> #    |     \   \
> You- + - D - E - C

Again, not quite: You can't pull C because that would lose the
information from E.


More information about the bazaar mailing list