simpler syntax for "diff since last merge"

[Martin Pool]

It's possible to say

  bzr diff -r ancestor:b1 b2

to show changes in b2 since the last common ancestor with b1. But this is a bit unobvious. Perhaps we should have say

  bzr diff --since-merge b1 b2

or

  bzr diff --ancestor b1 b2

(where b1 and b2 are branch names)

What this is actually meant to show is, as a diff, things that are new in b2 and not yet merged into b1.

[Steve Alexander (stevea)]

This is a common requirement for Launchpad development. The question I often want to answer is, what changes will I be responsible for merging... what code do I need to get reviewed.

Generally, I'll start off working on some code by branching mainline, doing some work, and then sending the diff between mainline and my work off to a reviewer to approve it.

The tricky thing is that while I've been working, other people have been landing changes on mainline, so mainline is a moving target. So, to get an accurate idea of what changes I'm proposing to merge, I need to merge mainline into my branch, resolve any conflicts, and then get a diff between my new mainline, and the mainline I just merged into my branch, and send that off to a reviewer.

Also, I want to see this diff myself, as I want to be very aware of what work I'm contributing to the mainline. This is moving my sense of responsibility and ownership away from "I have written this code" in the direction of "I want to improve this common endeavour". The empasis is not on the work I have done, but on the changes I propose to make to the common property.

When I ask for the diff, I don't want a diff against the current mainline, because that may have changed since I merged from it. I want to diff against the mainline I merged from.

[Andrew Bennetts (spiv)]

> This is a common requirement for Launchpad development. The question I
> often want to answer is, what changes will I be responsible for
> merging... what code do I need to get reviewed.
[...]
>
> When I ask for the diff, I don't want a diff against the current
> mainline, because that may have changed since I merged from it. I want
> to diff against the mainline I merged from.

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

Then what you really want is the diff produced by:

   bzr branch mainline tmp
   cd tmp
   bzr merge ../steve's-changes
   bzr diff

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.

So really what Steve needs is more "--if-merged-into" than "--since-merge".

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!

[Aaron Bentley (abentley)]

-----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-----

[John A Meinel (jameinel)]

I wanted to second Aaron's comment and make it clear...

'bzr bundle ../other/branch' contains the same human-readable diff as
'bzr diff -r ancestor:../other/branch'

I often switch between them when posting things to the mailing list. (Once the history gets long enough, a bundle can be 5x+ the size of a plain diff, for no benefit when reviewing, and my branches are all available online).

[Andrew Bennetts (spiv)]

> > 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.

I'm a turkey. I tested it locally, but screwed up. You are of course right.

[Christopher Armstrong (radix)]

Just to be clear—my impression is that there are cases where the diff given while merging a branch into another branch is different from anything you can easily do with "diff" without "merge", right? Is that what this ticket is about? If so, is the title of the ticket accurate?

[Aaron Bentley (abentley)]

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

Christopher Armstrong wrote:
> Just to be clear—my impression is that there are cases where the diff
> given while merging a branch into another branch is different from
> anything you can easily do with "diff" without "merge", right?

Not really. As long as you specify the correct revision, you can
generate an identical merge.

The "-r ancestor:" option just provides a way to avoid having to
remember or calculate the correct revision.

Also, there is now the '-r submit:' specifier, which automatically
generates a diff against the common ancestor with the submit branch.

So I would say the title is accurate.

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

iD8DBQFGUyC40F+nu1YWqI0RAmfgAJ9jE3EeH3JnIvSmlTkubfUj/GreNgCdG8Xd
kQaSUZuAedAkroFw8JIJ2sI=
=I8Cm
-----END PGP SIGNATURE-----

[Aaron Bentley (abentley)]

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

Aaron Bentley wrote:
> Christopher Armstrong wrote:
>> Just to be clear—my impression is that there are cases where the diff
>> given while merging a branch into another branch is different from
>> anything you can easily do with "diff" without "merge", right?
>
> Not really. As long as you specify the correct revision, you can
> generate an identical merge.

I mean "identical diff", obviously.

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

iD8DBQFGUymv0F+nu1YWqI0RAljkAJ9oF43Mu2UWxqVdP8J5qr4DjQfCgQCfYv9e
SL4rmHvsVNJzxNK1KlTY3sY=
=jVid
-----END PGP SIGNATURE-----