git send-email improvements

[Pierre Habouzit <madcoder@debian.org>]

The teaser
==========

This series has been sent using:
  git send-email --to git@vger.kernel.org --compose --annotate HEAD~3..


The series
==========

Here is a patch series to improve git send-email following our
discussions at GitTogether'08, despite my hate for perl.

The first patch is a minor nitpick, because leaking fd's sucks.

The second patch allow git-send-email to receive revision lists as
arguments. This doesn't allow complex arguments combinations as it
proces the revision lists one by one (IOW ^$sha1 $sha2 won't work as
expected _at all_) but this shouldn't be a problem since this command is
primarily used for interactive users. People wanting to use
git-send-email with complex revision lists through scripts MUST
git-format-patch first into a safe temporary directory and use
git-send-email on this afterwards.

The last patch adds the possibility to review patches into an editor
before sending them, which allow you (thanks to patch 2) to serialize,
review, annotate, and send patches in one command.


Further discussion
==================

I think one could make git send-email better doing this:

(1) make --compose and --annotate default, do not asking for a Subject
    if it's missing, neither should we ask for the in-reply-to if it's
    missing.

    Then spawn the editor with a first empty file that contains rougly a
    template looking like this:

        ----8<----
        GIT: Purge this buffer from any content if you don't want a series summary
        GIT:
        GIT: Lines beginning in "GIT: " will be removed.
        GIT: Consider including an overall diffstat or table of contents
        GIT: for the patch you are writing.
        GIT:
        GIT: Please fill a Subject if missing
        GIT: Leave the In-Reply-To field empty if not applicable.
        Subject:
        In-Reply-To:
        --> <we may want to add some more headers here: To/Cc/Bcc/...>

        GIT: put the content of the mail below this line


        GIT: [PATCH 1/10] ....  \
        GIT: [PATCH 2/10] ....   | this would contain all the Subject's
        [...]                    | from the commits that are beeing sent
        GIT: [PATCH 8/10] ....   | as a conveniency for people not
        GIT: [PATCH 9/10] ....   | having to cut&paste them
        GIT: [PATCH 10/10] .... /
        ---->8----

    I suggest we don't enable --compose when the series is reduced to
    one patch, as the usual way is to comment inline. This is probably
    arguable.

(2) Introduce a --batch option that basically:
    * turns --compose and --annotate off
    * turns any interactive feature off
    * complain (and fail) if it misses any information that is usually
      asked interactively

What do you think ?