Comment 3 for bug 65265

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Bennetts wrote:

> For the case of reviewing changes that will be merged, diff against the last
> ancestor isn't necessarily correct. If Steve does this fairly common sequence:
>
> * branches off mainline
> * makes some changes
> * merges in more recent mainline
> * makes more changes

[...]

> There's (generally) no ancestor you can pick in this scenario that will produce
> the diff that merge creates. Diffing against the original branch point will
> show changes Steve didn't make and have already been merged in by someone else,
> and diffing against the most recently merged revision will omit some of the
> changes Steve did make.

That's not correct. The whole point of picking a common ancestor when
merging is to find a good basis for comparison.

Since mainline hasn't merged Steve, the ancestor that is picked will be
the last revision that Steve merged. So when the comparison is done,
all the diffs shown are changes that Steve has introduced that have not
yet been merged.

It's not a thoroughly accurate predictor of what merge will do, because
it won't predict conflicts. But it is definitely accurate enough to be
useful.

> I'd find such a feature useful. Come to think of it, I believe that "bzr bundle
> -rbranch:b1 | filterdiff" produces such a diff already!

bzr bundle uses the common ancestor to produce the human-readable diff.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFLTvt0F+nu1YWqI0RAqHfAJ9MnPj2/d1Mnm2w6rFFISgg+OvuGgCfeif7
ZFIQiDNZ15qz+G+Hc9UtvZc=
=6X6K
-----END PGP SIGNATURE-----