bzr diff <normal diff options> should not require --diff-options boilerplate

[Paul Sladen]

Compare the following two:

  git diff -w
  bzr diff --diff-options -w

the latter is excessively verbose. The word "diff" gets repeated twice, and the word "options" is superfluous.

Ideally bzr diff would pass any unrecognised arguments through to the diff call.

[Vincent Ladeuil (vila)]

  bzr alias diffw='diff --diff-options -w'

while verbose is quite nicely self-documented :)

  git diff -w
  bzr diffw

Passing unrecognized arguments (including typos !) to the diff call are likely to cause error messages quite cryptic to the unsuspecting user.

[Paul Sladen (sladen)]

Would it help if I labelled this "papercut". (Comparatively easy fix that currently impacts a large number of people).

[Aaron Bentley (abentley)]

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

On 11/08/2010 05:06 PM, Paul Sladen wrote:
> Would it help if I labelled this "papercut". (Comparatively easy fix
> that currently impacts a large number of people).

No, it would not help to label this "papercut". We do not agree that
this is a bug, so the relative ease of changing the behaviour is
irrelevant. As for impacting a large number of people, this is
difficult to accept, because this behaviour has existed since 2005, and
it seems like someone would have reported it already if it really did
affect a large number of people.

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

iEYEARECAAYFAkzYuCUACgkQ0F+nu1YWqI1tlQCcCIkJ2LXGIc3ipv/bYfkVC33X
hlAAnj6go4SivlIAyrqcvrPTx0d1joEd
=noD/
-----END PGP SIGNATURE-----

[Martin Pool (mbp)]

Thanks for suggesting this, Paul.

Vincent has a reasonable concern that passing everything through might
give confusing behaviour if we change options in future.

A few options:

 * pass through particular short and long options known to be
meaningful to gnu diff, thereby also making sure we don't accept them
ourselves in future (for example -w)
 * have a shorter version of --diff-options
 * have an option to turn this on (kind of an "unbreak me" option though)

--
Martin

[Paul Sladen (sladen)]

I think single-character whitelist pass-through (documented in the manpage) would work, the four common cases are:

  -a
  -b
  -w
  -U

(the four are also the single-letter intersection between "man bzr" and "man git-diff").

[Paul Sladen (sladen)]

"man diff" and "man git-diff" ...

[Martin Packman (gz)]

So, passing -w would silently invoke an external diff program in a subprocess, and likely produce very different results, or even "bzr: ERROR: [Errno 2] The system cannot find the file specified" if there is no external diff tool? At least --diff-options is noticable if not clear that involves a completely different code path.

[Martin Pool (mbp)]

The story is "As a user, I want to see a diff that ignores changes in whitespace, so I can see the important change to the text."

At the moment they can say "--diff-options -w" but as Paul points out this is a bit longwinded.

We can implement '-w' as an option to bzr diff. To start with, it can shell out to gnu diff, and fail (perhaps cleanly) if you don't have an external diff. Later on we can do it in process, which will be better for people on non-gnu systems.

[Martin Packman (gz)]

I think that would be a regression from the current interface and behaviour. This bug is filed on the assumption that Bazaar just makes it hard to parse some options to the underlying diff process for no apparent reason. That's not the case, bzr doesn't use an external diff unless --diff-options is given. Documenting new flags that would then fail for no apparent reason with the all-in-one installer (see bug 673114) is a nastier bug than requiring some extra typing in order to use an external diff.

[Paul Sladen (sladen)]

gz: if it helps, I can phrase this bug report as "perfectly normal everyday diffing options cause unnecessary {performance,codepath} callout to external diff process" and file the (frequent) need to use the external diff as a performance issue.

As poolie notes, as a user I'm unaware of whether I'm using an internal or external diff algorithm—the user just wants a short command for their everyday options and ideally should not be exposed to any difference in implementation behaviour for the most part.