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

[John Arbash Meinel]

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

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


This is a general issue with send not working quite the way people think it
does. Specifically, I'm guessing you are using a submit branch which is at the
same revision as the branch you are submitting. What you want is:

cd my-branch
bzr send -o ../my.patch ../upstream
~                        ^^- submit_branch ==> branch I am submitting *to*

The 'public-branch' is a convenience. It isn't strictly needed (I'm not sure if
'send' requires it). It is designed that if one is given, and the patch doesn't
include enough meta-information to merge, then bzr will be smart enough to go
contact your public branch and pull in the revisions it needs.

Actually, if you are giving --no-bundle, it probably *does* require a public
branch, since that is the only way to actually 'bzr merge' the change (as
opposed to just using 'patch').

At the moment, you always need 2 branches to be able to use 'bzr send'. As it
needs another branch tip to know what revisions are common, and what revisions
should be included in the transmission.

There has been a lot of discussion about something like "bzr send -r -4..-1 ."
which would look up the common revisions in the current branch, and then only
send the information for revisions -3,-2,-1. The problem is that sometimes
people would guess "-4" wrong, and then we were unable to merge their changes.
So Aaron changed it to require another branch, since people are much less likely
to get "../bzr.dev" wrong.

The workaround is to do:

cd ..
bzr branch -r -4 my-branch my-temp-upstream
cd my-branch
bzr send -o XXX ../my-test-upstream


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

I'm a little confused by your "one commit per feature" separate from "one big
patch". Don't you need multiple patches, one per feature? Or is the one big
patch actually a collection of patches. (I don't know how well Gnu patch works
with multiple changes to the same file, presumably it does ok.)

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

I think it is a just a simple confusion with how to get "bzr send" to do what
you want. If you have suggestions on what you tried, and maybe what hints we
could have given you to make it more obvious, we would love the feedback.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkghv30ACgkQJdeBCYSNAAPHHgCfeJerI8LX7Bh4t5f4WbgZg7WZ
FF8An2V5BBMAlw98pESYK9v5WVVBpSkt
=+eLZ
-----END PGP SIGNATURE-----