The teaser
==========
This series has been sent using:
git send-email --to git@xxxxxxxxxxxxxxx --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 ?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
