On Wed, 2012-10-24 at 10:40 +0200, Martin Kosek wrote: > On 10/23/2012 03:53 PM, John Dennis wrote: > > On 10/23/2012 09:00 AM, Simo Sorce wrote: > >> I strongly suggest you use git-send-email instead of thunderbird, it > >> makes everything a lot faster, see the instructions I sent in my > >> followup email. > > > > I wrote a python script to manage my patch submissions a while ago which > > might > > be useful to folks, it's attached. > > > > The basic idea is you keep a directory of your patch submissions. Inside the > > directory is also a file that has then next number to use for your > > submission. > > By default it runs git format-patch selecting the last commit. It creates a > > patch file using the patch submission format defined for IPA. If you use > > the -s > > option it also sends it to the list. It doesn't use git-send-email, rather > > it > > builds an email with a mime attachment according to our IPA > > recommendations. I > > don't recall why I didn't use git-send-email, but there was some reason > > (probably because I couldn't get it follow the IPA conventions, not sure > > though). > > > > If you have to rework a patch use the -n option to specify which patch > > you're > > modifying. The script automatically searches the patch directory and finds > > the > > next revision number for the patch. > > > > The config dict at the top will have to be modified to match your username, > > smtp server, etc. look for anything in UPPERCASE and replace with your > > specifics. > > > > I like to use it because I don't have to remember my patch numbers and the > > result will always follow the IPA conventions without any fumbling around. > > > > Petr3 will probably complain about using getopt and a config dict instead of > > optparse but it works and it wasn't worth it to me to port it to a different > > mechanism. Anybody which wants to is more than welcome. > > > > Hmm, yeah, I have similar script of my own, except I implemented a support for > sending a bulk of patches at once.
Should be easy to change it to send one per mail, however git send-email here has features you want to replicate like setting the correct in-reply-to header so they all belong to the same thread. > I think I am just too conservative, but I am perfectly comfortable with my > home-grown scripts which detect the next number(s) of sent patch, prepares me > an e-mail with attachments I can further amend and the script also attaches > the > patch to Trac ticket. It would be easy to change the script to use send-email and still do the other things you need, git send-email doesn't prescribe patch numbers or subjects. > I think someone other already pointed it out, but numbering patches also make > it easy both referring to them during discussions on IRC. I find it easier to give out a URL with the bundle from patchwork :) More than once lately I saw a number but multilpe people had similar numbers in play, but I am not against using numbers, just find there are simpler ways and not too critical. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel