Comment 3 for bug 449923

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

Andrew Bennetts wrote:
> A couple of thoughts:
>
> - Some --diff-options, like -p, would produce semantically equivalent
> diffs that bzr would parse ok. So if bzr generated the diff with
> --diff-options and then checked that it still validates like a regular
> diff would, then that could be useful.

The validation is text-based. If you don't generate the same text as
bzr itself would generate, validation will fail. It doesn't matter how
it parses. If we did use the parser to parse a -p-style diff, it would
fail, because our parser only parses vanilla unified diffs. If we
changed the parser to accept -p-style-diffs, it should parse the
information about function context and roundtrip it. If we changed the
parser to parse function context, then it should not consider two
patches equal that have different information about function context.

Finally, such merge directives would be incompatible with common
versions of bzr.

Simply adding support for --diff-options without revising the merge
directive format does not make sense.

> - Not all uses of 'bzr send' are intended to preserve perfect fidelity.
> e.g. a bzr send of a cherry-pick to an upstream that doesn't use bzr,
> you may as well just send a merge directive with no bundle

This doesn't really follow. When a bundle is omitted, then bzr uses the
specified branches instead. You still get perfect fidelity.

I think you mean a situation where the merge directive is applied as a
patch. But if want to provide a cherry-pick to an upstream that doesn't
use bzr, you should send a patch.

>, and as the
> target isn't bzr validation isn't a concern.

In any context where bzr data might be used rather than the patch, we
need to ensure that the patch is an honest representation of the merge
directive.

In any context where bzr data will not be used, we should not send the
bzr data-- we should just send a patch.

There are no cases where bzr send must be used but perfect fidelity need
not be maintained.

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

iEYEARECAAYFAkrX/BsACgkQ0F+nu1YWqI1QxwCePIvYsCxDskNAUvm+cKKA1BAb
zKcAn2XEe4pOp2aPEzjc1oEC4+CZFX16
=Y5r+
-----END PGP SIGNATURE-----