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

[Soren Hansen]

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

I tried "bzr send", but it didn't give me any love. Maybe there's just
something I'm missing about how to use it:

a) It requires me to specify a submit branch and a public branch. I'm
not sure what either of those are, but it smells like it wants a public
branch to be available, but I'm just trying to get it to output a simple
patch that I can send to someone. Whether or not they're in a public
branch shouldn't matter, should it?

b) When I decided to try to trick "bzr send" into doing what I want, I
did "bzr send --no-bundle -r 1234 --to=myself at mydomain.com . .". The
e-mail that it showed me (I'm using mutt (and have set mail_type
accordingly) if that matters) had an attachment that seemed to *only*
have the merge directive. The last line simply says: "# Begin
patch".

In short: I'm having very little luck :)

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

It sure does sound lovely :)

> So you want something that generates a series of patches, one per
> commit?  

That was the idea, yes.

> 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'm not the vcs wiz here :), but I don't see how these two concepts are
intertwined in any reasonable way? I work on a series of changes for an
upstream project, and their style is to have one commit per "feature",
so locally I created a branch for each of these (so that I could commit
every time I felt like I had something that was worth keeping), and then
merged them back into the main branch. What I'd like for the
format-patch command to do is to just make one big patch out of this
merge, so that all of my intermediate commits are never seen by
upstream.

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

Well, if I could just get it working, I imagine I could tweak it until
it does what I'd like it to do.  It's hard to say at this point, though
:)

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

I appreciate these concerns. However, I think it's useful to keep in
mind that some people are using bzr to work on things that the upstream
projects keep in git (or CVS, Mercurial, Subversion, etc.), and as such
it would be rather useful if bzr could be, if not directly helpful, then
at least not get in the way of the workflow that people's upstreams
require.

-- 
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/
-------------- 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/c659a4a0/attachment.pgp