Re: [PATCH] Documentation: add a planning document for the next CLI revamp

On Thu, 30 Oct 2008, Pierre Habouzit wrote:

On Thu, Oct 30, 2008 at 03:48:05AM +0000, Sam Vilain wrote:

quoted

+Working with patches
+--------------------
+
+  * 'git send-email' should prompt for all SMTP-related information
+    about sending e-mail when it is running with no configuration.
+    Because these days /usr/lib/sendmail is rarely configured
+    correctly.

And when the user answer them, it should set them (a bit like zsh does
when it's run from the first time e.g.)

quoted

+
+  * other git send-email functionality which has bitten people -
+    particularly building the recipient list - should prompt for
+    confirmation until configured to be automatic.
+

 * git-send-email should be either more interactive, or less: either
   just use the damn configuration, or propose a mode where it spawns
   an editor for each patch so that you can add further comments.

 * git-send-email should be able to format-patches by himself (IOW
   accept most of format-patch arguments and deal with the patch list
   by himself, which is usable if the previous point is implemented).

This gets my vote ...

These are two of the reasons that I ended up ignoring git-send-email and 
writing my own replacement.  I found the whole format-patch/send-email 
dance too cumbersome and confusing - particularly for sending a single 
patch.  To send a single patch I ended up with the command:

git mail-commmits --edit HEAD~1

It would be nice if I could replace this with:

git send-email --edit HEAD~1

;)

quoted

+  * 'git am -3' the default; with global option to make it not the
+    default for those that prefer the speed of -2
+
+

-- 
Julian

  ---
Blessed be those who initiate lively discussions with the hopelessly mute,
for they shall be know as Dentists.