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

On Sun, Nov 02, 2008 at 06:23:55AM +0000, Junio C Hamano wrote:

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!