Re: [PATCH 3/3] git send-email: add --annotate option

[Pierre Habouzit <madcoder@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 4020 bytes --]

On Sun, Nov 02, 2008 at 06:23:55AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> 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@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]