Simple way to prepare patches for submission

[CC'ing the mailing list, as feature discussions are usually better held there
than in bug reports.]

[For the benefit of the mailing list, the original bug report is at
<https://bugs.launchpad.net/bzr/+bug/227340>.]

Soren Hansen wrote:
[...]
> This is usually where bzr people tell me about "bzr bundle", but seeing
> as I interact with people who use all sort of crazy VCS's (e.g. by way
> of cvs imports on launchpad or bzr-svn or whatever), it'd be nice to be
> able to generate vcs agnostic patches for submission to mailing lists.

"bzr send" (which replaces the deprecated "bzr bundle" command) does generate
VCS agnostic patches. By default it also includes a big base64 blob of bzr
metadata, but that doesn't interfere with the validity of the patch. Also, you
can use "bzr send --no-bundle" to omit that blob entirely.

So, bzr send already produces output that GNU patch will happily use, which is
about as vcs agnostic as you're going to get :)

> "git format-patch" in its simplest form takes a revision as an argument.
> Each commit since the given revision is put into a file (with numbered
> prefixes to keep the ordering intact). The contents of each file looks
> very much like that of "git show", except "Author: " is replaced by
> "From: ", and the first line of the commit message is used as the
> subject to make it look like an e-mail. It has an "--in-reply-to" option
> so that you can respond to threads properly with it, it has a --thread
> option to create a new thread (puts a message-id into the first and
> references that from all the others).

So you want something that generates a series of patches, one per commit? I'm a
bit ambivalent about that, as that's the sort of behaviour that encourages (and
is encouraged by) rebasing, which has significant drawbacks. I'd prefer to find
a way to satisfy your need that doesn't encourage rebasing if possible.

Two thoughts:

 - probably whatever we do for this should be another argument to "bzr send"
   (which already understands email and is the right place for options like
   --in-reply-to anyway). I'd like to hear your thoughts on using "bzr send"
   for this.
 - that said, I wonder if using the loom plugin in conjunction with teaching
   "bzr send" to deal nicely with looms (see e.g.
   https://lists.ubuntu.com/archives/bazaar/2008q2/040104.html) would be better.

I hope it doesn't sound like I'm saying "you must use the One True Workflow".
I'm just trying to understand if there's a better way to satisfy the high-level
goal in bzr than just copying git, particularly since git and bzr tend to
encourage slightly different ways of working. So simply transplanting a command
from git into bzr is likely to be a bit unsatisfying for everyone.

-Andrew.

Using "bzr send --no-bundle" _could_ work - but it has some drawbacks:

- it needs a public branch. And I needed some time to figure out, that I could also use "." as a public branch. But as you can't give the public branch as a named argument, you also have to include the submit (so: in most cases the parent) branch explicitly. - So (if you don't want to change something in .bzr/locations.conf) you need to use:

    bzr send --no-bundle $PARENT .

Which is ugly to type -- and (at least for me) "gittish" (read: overly complex)

- the mail still contains quite a bunch of metadata. This might annoy people which are not using bzr.

Whether the "to-be-written" command merges all commits into one diff or creates one diff per commit, is not really important imho. Because this can easily be controlled using a commandline switch :)

I just need a simple replacement for the "bzr diff -rthread:..-1 > some.patch && write mail && attach patch to mail" procedure :).