[Bug 227340] [NEW] Simple way to prepare patches for submission

Andrew Bennetts andrew at canonical.com
Wed May 7 02:17:33 BST 2008


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080507/98df416a/attachment-0001.pgp 


More information about the bazaar mailing list