On Sun, Nov 02, 2008 at 06:23:55AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@xxxxxxxxxx> writes:
>
> > This allows to review every patch (and fix various aspects of them, or
> > comment them) in an editor just before being sent. Combined to the fact
> > that git send-email can now process revision lists, this makes git
> > send-email and efficient way to review and send patches interactively.
>
> Without your patches, you run format-patch (with or without cover), you
> use the editor of your choice to massage them and feed the resulting files
> to send-email.
>
> Only because you wanted to allow format-patch parameters to be given to
> send-email, you now need to also allow the messages to be massaged before
> they are sent out.
>
> Is it only me who finds that this series creates its own problem and then
> has to solve it? What are we getting in return?
Actually my problem is that the current workflow is:
$ git format-patch [rev-list]
$ vim *.patch
# massage patches
$ git send-email [argument list too long to copy] --compose *.patch
# struggle in vim to reopen the patches I'm about to comment to copy
# the Subject lines and other similar stuff
# answer to a lot of silly questions that git-s-e should guess from
# the cover.
*also* I often have other patches in my repository, and this send-email
sometimes globs _too many_ patches and this is a big problem for me.
Basically that and all the '#' bits, and the number of commands to type
are what make me dislike git-send-email (but still use it since there
are no good alternatives yet that automate the task).
With my patch series, the workflow is as follows:
$ git send-email --to <where> --annotate [rev-list]
# as vim can open many files at once, I have the cover opened _and_
# all the patches at once, or only the patch if there's one single
# patch I can massage everything I want.
# answer 'y' to the _single_ question git-s-e asks.
# or 'n' if something doesn't fly.
Not only the command line is considerably shorter (even the --to can be
omited actually, but unlike --in-reply-to, it rarely changes and it's in
the history so...), but more importantly I can see what I will send, no
more '*.patch' that will bite me hard. I don't have to struggle opening
all the patches I'm interested in reading while I comment them in the
cover, and so on.
I mean you're mistaken when you say:
] Only because you wanted to allow format-patch parameters to be
] given to send-email, you now need to also allow the messages to be
] massaged before they are sent out.
Your causality is backwards. I _DO_ want git-send-email to allow me to
do the cover _and_ the massaging at once. It's actually the first patch
I wrote locally even if I reordered the series before sending for some
reason I don't remember. *Then* if you do that, there's little point in
having to perform git-format-patch in the first place, hence I wanted
the feature to let git-format-patch be run by git-send-email directly.
I don't know for others, but with those series, git-send-email is
_REALLY_ what I would have wanted it to be from day 1. The sole little
issues I can see are:
* the To:/Cc:/Bcc:/other headers parsing directly from the cover, for
that someone better skilled than me shall add a last patch to do that
properly.
* when you only edit one single patch, it doesn't do the From/To/Cc/...
parsing and you'll get all the silly interactive questions again.
That should probably addressed, but to be frank I care about this one
less, because I send single patches directly from mutt. So it's not
really my itch to scratch[0] ;)
[0] WHO SAID I'M LAZY ? Yeah you in the back, I HEAR YA!
--
·O· Pierre Habouzit
··O madcoder@xxxxxxxxxx
OOO http://www.madism.org
Attachment:
pgpscSzfrSdyq.pgp
Description: PGP signature
