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

[Soren Hansen]

On Wed, May 07, 2008 at 09:41:01AM -0500, John Arbash Meinel wrote:
> 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*

Ah, ok. I suppose I could do that.

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

Er.. You seem to be missing the core of my problem. I interact with
projects that use *different* vcs's (go figure). They couldn't be less
interested in having a bzr tree to merge from. They want plain patches.

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

/me grumbles a bit

If I promise to get the -4 right, can I pretty please get an option to
do that? :)

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

I'll try and put it into bzr terms :)  

$ bzr branch lp:libvirt libvirt.upstream
$ bzr branch libvirt.upstream libvirt.cool-feature
$ cd libvirt.cool-feature
[ hack ]
$ bzr commit -m "something"
[ hack some more ]
$ bzr commit -m "getting close"
[ hack some more ]
$ bzr commit -m "ah, now it's done"
$ bzr diff ../libvirt.cool-feature > ../this_is_what_I_call_a_big_patch
$ cd ..

There are four commits, but they can be represented by one big patch.
It's this one big patch, I'd like to send upstream, and never bother
them with my intermediate commits.

What would be convenient for me was if the above transcript could
continue as such:

$ bzr branch libvirt.upstream libvirt.other-cool-feature
$ cd libvirt.other-cool-feature
[ hack ]
$ bzr commit -m blah
[ hack hack ]
$ bzr commit -m blah\ blah
[ rinse, repeat ]
$ bzr commit -m "yay, all done"
$ cd ..
$ cd libvirt.upstream
$ bzr merge ../libvirt.cool-feature
$ bzr commit -m "Long, useful commit message describing my cool new feature"
$ bzr merge ../libvirt.other-cool-feature
$ bzr commit -m "Long, useful commit message describing my other cool new feature"

After this, "bzr send --appropriate-options -r -2" should first fire up
mutt, use my commit message as a template for the body of the e-mail,
and attach the big patch that represents the first merge (or optionally
add it inline (some upstreams want them inline or they'll get
surprisingly annoyed)), send the e-mail, and then repeat that process
for the next merge. I'm happy because I got through another day without
having to deal with git, and I still have all my history, and my
upstream is happy because they don't have to deal with another vcs to
get their hands on my cool, new code.

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

I hope the above outlines it rather well.

-- 
Soren Hansen               | 
Virtualisation specialist  | Ubuntu Server Team
Canonical Ltd.             | 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/5a060cd1/attachment-0001.pgp