Re: git-send-mail in sh

[Andreas Ericsson <ae@op5.se>]

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
>>It's worse than the perl version because;
>>1. It doesn't thread the patch-series (which I personally prefer anyway 
>>since it's easier to follow a thread on a particular patch that way).
> 
> 
> I think that is an improvement, actually ;-)
> 

Agreed to that then. Good thing since that was the hardest to solve.

> 
>>2. The patches sent within the same second arrive in random order.
> 
> 
> I think you can fudge the "Date: " yourself.  Count the number
> of messages you are going to send out, grab the wallclock time
> before starting to send the first message, subtract that number
> of seconds and give it to the first message, add 1 second and
> give it to the second message, and so on.
> 
> 3. It does not CC signers and authors.  Although I personally
> consider not doing it "better", some people _might_ want to keep
> that behaviour as an option.
> 

It doesn't CC them, but any number of email-addresses can be specified 
on the command line (so long as they don't include spaces, but that can 
be taken care of).

These below needs a bit of clarification. It's friday afternoon here, so 
I'm a bit slow.

>         <commits> = ".." <top> | <bottom> ".." <top> | <commit>
> 	<bottom> = <extended SHA1 expression>
> 	<top>    = <extended SHA1 expression>
> 	<commit> = <extended SHA1 expression>
> 
>  * ..<top> is a shorthand of "origin"..<top> (the choice of
>    "origin" might be debatable, but probably sane).
> 

I'd rather specify the entry-point, as in "get all patches from this 
commit to HEAD", if only one commit is specified, so:

	git-send-patch git@vger.kernel.org origin

would do just that.

>  * <bottom>..<top> pair is to format changes in <top> but not in
>    <bottom>; typically <top> is the name of a topic branch, and
>    <bottom> is typically "origin".  This is to encourage the use
>    of topic branches.
> 

Would that be

	git-send-patch origin..HEAD

to get the changes in the current branch since head?

>  * <commit> is a shorthand for <commit>^1..<commit>; this is to
>    allow you to quickly pick just one commit and send it out.
> 

Marvellous the things one learn. I didn't know about that syntax before. :)

> 
>># [ "$email" ] || git repo-config --get patch_email_address
> 
> 
> Storing the default addressee in the config is a good idea,
> since typically e-mail submissions are to a single address.
> 

If values can have spaces there can be any number of email-addresses.

> 
>>[ $commits -gt 1 ] && opts=-n
> 
> 
> You can always say -n if you want to do this; format-patch -n
> with a single patch would not say [PATCH 1/1].
> 

Didn't know that. Good thing though.

> 
> This is the first script I saw that uses the standard output
> from format-patch, and I do not think nobody else used it so
> far.  If the standard output from format-patch is useful like
> this, I would like to drop the '* ' prefix from it, so that you
> do not have to sed it out.
> 

I'll do that then. It doesn't really add any value anyways.

> You would probably want to do "format-patch -o $tmpdir" at least
> not to smudge the toplevel directory.
> 

Perhaps support the -o flag in git-send-patch?

I'm wondering if it wouldn't be better to move much of 
git-format-patch's functionality to git-send-patch and support a 
"--todisk" option. After all, how many patches are created but not sent 
anywhere?

That way we could rework the syntax to only support that of 
git-rev-list. I think it's the most standard-like thing there is in git.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231