bzr diff -rNNNN is undocumented

Brad Bollenbach wrote:
> Public bug reported:
> https://launchpad.net/malone/bugs/6391
>
> Affects: bzr (upstream)
> Severity: Normal
> Priority: (none set)
> Status: New
>
> Description:
>>From bzr help diff:
>
> usage: bzr diff [FILE...]
> aliases: di, dif
>
> Show differences in working tree.
>
> If files are listed, only the changes in those files are listed.
> Otherwise, all changes for the tree are listed.
>
> examples:
> bzr diff
> bzr diff -r1
> bzr diff -r1..2
>
> options:
> --diff-options ARG
> --help, -h show help message
> --revision ARG, -r
>
> This help doesn't tell me, in clear and simple terms, what "bzr diff
> -r1" will tell me about revno 1. I thought I could get the diff of what
> changed only in revno 1 with "bzr diff -r1", but that command appears to
> show something else.
>
> It seemed I had to do "bzr diff -r2934..2935" to see what changed in
> revno 2935, but I should have to specify only the revno I'm interested
> in to get diff information about that revno, not the number of the revno
> before it as well.
>

The documentation does need to be updated.

bzr diff
  - Show the differences between the working tree and the last commit
bzr diff -rX
  - Show the difference between the working tree and revision 1
bzr diff -rX..Y
  - Show the difference between revision Y and revision X

I think this is a fairly common interpretation for a 'diff' command. I
agree it would be nice to have an easier way to show the changes for a
single revision. (with my changeset plugin I had, bzr cset -r 1 which
did exactly that, though it is currently bit-rotted).

John
=:->

On 3 Jan 2006, John A Meinel <email address hidden> wrote:
> > This help doesn't tell me, in clear and simple terms, what "bzr diff
> > -r1" will tell me about revno 1. I thought I could get the diff of what
> > changed only in revno 1 with "bzr diff -r1", but that command appears to
> > show something else.
> >
> > It seemed I had to do "bzr diff -r2934..2935" to see what changed in
> > revno 2935, but I should have to specify only the revno I'm interested
> > in to get diff information about that revno, not the number of the revno
> > before it as well.
> >
>
> The documentation does need to be updated.
>
> bzr diff
> - Show the differences between the working tree and the last commit
> bzr diff -rX
> - Show the difference between the working tree and revision 1
> bzr diff -rX..Y
> - Show the difference between revision Y and revision X

I agree the help message and the tutorial should be fixed.

As a separate issue, I think we should change the behaviour to be what
bradb expected, i.e. "bzr diff -r 40" is equivalent to 39..40. The
behaviour of diffing 40 to the current version is less commonly used,
and should be easy to get with "40..".

--
Martin

On Wed, 2006-01-04 at 07:06 +0000, Martin Pool wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/6391
>
> Comment:
> On 3 Jan 2006, John A Meinel <email address hidden> wrote:
> > > This help doesn't tell me, in clear and simple terms, what "bzr diff
> > > -r1" will tell me about revno 1. I thought I could get the diff of what
> > > changed only in revno 1 with "bzr diff -r1", but that command appears to
> > > show something else.
> > >
> > > It seemed I had to do "bzr diff -r2934..2935" to see what changed in
> > > revno 2935, but I should have to specify only the revno I'm interested
> > > in to get diff information about that revno, not the number of the revno
> > > before it as well.
> > >
> >
> > The documentation does need to be updated.
> >
> > bzr diff
> > - Show the differences between the working tree and the last commit
> > bzr diff -rX
> > - Show the difference between the working tree and revision 1
> > bzr diff -rX..Y
> > - Show the difference between revision Y and revision X
>
> I agree the help message and the tutorial should be fixed.
>
> As a separate issue, I think we should change the behaviour to be what
> bradb expected, i.e. "bzr diff -r 40" is equivalent to 39..40. The
> behaviour of diffing 40 to the current version is less commonly used,
> and should be easy to get with "40..".

Eh? That seems awfully surprising to me, and not at all like CVS, svn or
baz.

Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

> > As a separate issue, I think we should change the behaviour to be what
> > bradb expected, i.e. "bzr diff -r 40" is equivalent to 39..40. The
> > behaviour of diffing 40 to the current version is less commonly used,
> > and should be easy to get with "40..".
>
> Eh? That seems awfully surprising to me, and not at all like CVS, svn or
> baz.

I haven't used cvs in years. I was also surprised by -r 39..40

--
James Blackwell's home : http://jblack.linuxguru.net
Gnupg 06357400 F-print AAE4 8C76 58DA 5902 761D 247A 8A55 DA73 0635 7400

On Wed, 2006-01-04 at 23:15 +0000, James Blackwell wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/6391
>
> Comment:
> > > As a separate issue, I think we should change the behaviour to be what
> > > bradb expected, i.e. "bzr diff -r 40" is equivalent to 39..40. The
> > > behaviour of diffing 40 to the current version is less commonly used,
> > > and should be easy to get with "40..".
> >
> > Eh? That seems awfully surprising to me, and not at all like CVS, svn or
> > baz.
>
> I haven't used cvs in years. I was also surprised by -r 39..40

in cvs it is '-r 39 -r 40'
in svn IIRC its '-r 39:40'
in baz its (for baz delta) '39 40'

Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

We should improve the documentation here. I'm not sure the syntax needs to change - adding concrete data on what the examples in 'bzr diff --help' do would probably solve the problem.

Although I would love for `bzr diff -r N` to output just the changeset
for revision N (like e.g. `bzr log -r N` does), I can see why one would
prefer not to change it now, specially if taking into account that
current behavior is the same as that of many other VCS.

However, I really think that having built-in syntax/command to output
the diff for a single revision without having to specify anything more
than N, would be quite good to have.

On Tue, Jun 20, 2006 at 01:12:45PM -0000, Adeodato Simó wrote:
> Although I would love for `bzr diff -r N` to output just the changeset
> for revision N (like e.g. `bzr log -r N` does), I can see why one would
> prefer not to change it now, specially if taking into account that
> current behavior is the same as that of many other VCS.
>
> However, I really think that having built-in syntax/command to output
> the diff for a single revision without having to specify anything more
> than N, would be quite good to have.

I don't suppose you mean typing only one revno, 'bzr diff -r before:N..N'
which does save having to subtract 1. Quite often when I want to look at
changes introduced in a revno they are recent, and I use something along
the lines of 'bzr diff -r -2..-1'.

Is there one specific case people want to see what was introduced?
If it needs to be more generic, should it be an option to diff, a
revisionspec, a new command?

bzr diff --introduced 40
bzr diff -r intro:40
bzr introduced -r 40

Wouter van Heyst

I've always thought that we could do:

bzr diff -r ..N

At present a missing revision specifier is implementation dependent. So making diff see that as 'oh, you meant the one right before it' would be great for me.

We should probably look a little at consistency versus what the common actions are. Right now 'bzr log' includes the endpoints, and a missing value means go to the end. (bzr log -r .. gives all revisions, or at least used to).

On Tue, Jun 20, 2006 at 02:51:06PM -0000, John A Meinel wrote:
> I've always thought that we could do:
>
> bzr diff -r ..N
>
> At present a missing revision specifier is implementation dependent. So
> making diff see that as 'oh, you meant the one right before it' would be
> great for me.

Hmm, I'm not sure if it is a good idea to vary what ranges do per
command. But blowing up the amount of commands/options also is
suboptimal :/

> We should probably look a little at consistency versus what the common
> actions are. Right now 'bzr log' includes the endpoints, and a missing
> value means go to the end. (bzr log -r .. gives all revisions, or at
> least used to).

bzr log -r N does give the log introduced in rN, but 'log between
working tree and N' doesn't make much sense. Feh, we already do
different things per command.

Wouter van Heyst

> However, I really think that having built-in syntax/command to output
> the diff for a single revision without having to specify anything more
> than N, would be quite good to have.

For example, svn diff accepts now (or will, in 1.4) a -c option that
accepts just a revision number:

http://svn.collab.net/viewvc/svn?view=rev&revision=17054

Perhaps just having a different option is the simplest thing. I don't
think we should be too dependent on composing complicated revision specs
when there are common special cases that can be separately handled.

This discussion needs to go the list .. but I like the idea that 'bzr diff -r x' gives me just the diff from x-1 to x.

I am constantly typing 'bzr diff -r (x-1)..x', and I can't ever think of when I've wanted the diff from x to the working tree. If I did I think I'd work out x.. pretty quickly.

This may be different to cvs/svn, but IMHO it's sufficently better to warrant it.

(Not relevant to the discussion of whether `bzr diff -rN` changes in
trunk or not, but if somebody reads this bug and would like -rN to mean
-r N-1..N, the plugin below implements it.)

http://people.debian.org/~adeodato/code/bzr/plugins/private/adeodato/cmd_diff_single_rev.py

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

Michael Ellerman wrote:

> I am constantly typing 'bzr diff -r (x-1)..x', and I can't ever think of
> when I've wanted the diff from x to the working tree. If I did I think
> I'd work out x.. pretty quickly.

I should just point out that I often use single revnos. I strive to
make minimal changes. If I produce commits 2 and 3, and 3 undoes some
changes that 2 made, I will do 'diff -r 1', to make sure I haven't
introduced spurious whitespace changes, etc.

The most recent case of this was last night, when I actually did "shelve
- -r 69" on the bzr-gtk plugin, to remove some changes that were no longer
needed.

So I think both cases are important, and we should make sure both are
handled well.

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

iD8DBQFEn/420F+nu1YWqI0RAkF+AKCE5MMJM3eNdXmTnv2G2v2yyaSPWwCfdiF2
z18wRE4HT984JZjRBXHND0w=
=B0e3
-----END PGP SIGNATURE-----

Updated the documentation for 'bzr dif --help'