Question/idea about multiple developers committing to one branch

John Arbash Meinel john at
Sun Dec 3 16:26:27 GMT 2006

David Allouche wrote:


> Currently, when feature merges from mainline, the diff is unusably large
> because it includes the work for the whole team on the whole project, so
> it's effectively impossible to review before committing. One must just
> blindly trust the merge code.
> (Actually it is possible to review the merge by manually diffing against
> a tree of the mainline revision being merged, but it is too difficult to
> bother with for anybody but the most anal retentive).

Have you tried:

$ bzr merge ../mainline
#Resolve conflicts
$ bzr commit -m 'merged mainline'
$ bzr diff -rancestor:../mainline

ancestor: says to use the common ancestor between this branch and
another branch. After merging the mainline, the common ancestor is
typically the last revision in the mainline, for fairly obvious reasons.

I realize it is a little bit more to type, and we can try to make this
sort of thing easier. (I'm not opposed to merge --to, I just think we
already have a solution for your particular use case.)

The other nice thing about 'ancestor:' is that it works in more complex
situations, because it is selecting the same revision that the merge
code is going to select when it decides how to merge things.


> mainline  A ----- TONS
>            \          \
> feature     `- B - C - D
> Here, the diff displayed before committing D is unusably large.
> With "merge --to", this situation would become something like this:
> mainline  A -- TONS -.
>            \          \
> feature     `- B - C   `- D
>                     \    /
>                      `--'
> In this case, the diff before committing D shows the changes introduced
> by B+C, which is just what I want to see to review the merge.
> In my initial suggestion, I asked for an option to diff, like "diff
> --merge", to get the diff against the merged parent, instead of the diff
> against the leftmost parent. These two solutions produce very different
> logs, but both fix the review problem equally well.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : 

More information about the bazaar mailing list