[PATCH RFC] git-send-email --expand-aliases

[PATCH RFC] git-send-email --expand-aliases

[Alex Chiang]

I'm an StGit user, and while StGit has its own 'stg mail'
feature, it doesn't know how to expand email aliases (yet).

Certainly, one way to solve that problem would be to hack stgit
so that it can parse alias files, but to me, that seems silly
when git-send-email can already do that.

This patch teaches git-send-email to only expand email addresses
so that other git porcelains don't have to roll their own mail
alias parsers.

I imagine the internal implementation of stg mail to work
something like:

	call git-send-email --expand-aliases repeatedly, once for
	all the combined --to= args, then for all the combined --cc= args,
	and finally for all the combined --bcc= args (all passed
	to stg mail), read from stdout until EOF

That API is a little ugly, requiring 3 calls to git-send-email
for each class of recipient (to, cc, bcc).

The other interface that I thought of would be to have
git-send-email print a heading like:

	TO
	<expanded alias 1>
	<expanded alias 2>
	CC
	<expanded alias 3>
	BCC
	<expanded alias 4>

But, that requires more parsing in the porcelain. Requiring a
call to git-send-email for each class of recipient seems like a
reasonable interface for what will presumably be an API only used
in an automated manner by a porcelain like stg (and possibly
guilt?).

I haven't patched stg yet, wanted to see what the feedback on
this RFC patch was first. If folks are receptive, I can send a
fuller patch with expanded help text, etc.

Thanks,
/ac

---
diff --git a/git-send-email.perl b/git-send-email.perl
index a0279de..ac34bec 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -79,6 +79,7 @@ git send-email [options] <file | directory | rev-list options >
                                      auto, cc, compose, always, or never.
     --quiet                        * Output one line of info per email.
     --dry-run                      * Don't actually send the emails.
+    --expand-aliases               * Expands email aliases only and exits
     --[no-]validate                * Perform patch sanity checks. Default on.
     --[no-]format-patch            * understand any non optional arguments as
                                      `git format-patch` ones.
@@ -156,7 +157,7 @@ if ($@) {
 }
 
 # Behavior modification variables
-my ($quiet, $dry_run) = (0, 0);
+my ($quiet, $dry_run, $expand_aliases_only) = (0, 0, 0);
 my $format_patch;
 my $compose_filename;
 
@@ -263,6 +264,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
 		    "suppress-cc=s" => \@suppress_cc,
 		    "signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
 		    "confirm=s" => \$confirm,
+		    "expand-aliases" => \$expand_aliases_only,
 		    "dry-run" => \$dry_run,
 		    "envelope-sender=s" => \$envelope_sender,
 		    "thread!" => \$thread,
@@ -441,6 +443,22 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
 	}
 }
 
+if ($expand_aliases_only) {
+	my @expand_to = expand_aliases(@to);
+	my @expand_cc = expand_aliases(@initial_cc);
+	my @expand_bcc = expand_aliases(@bcclist);
+
+	@expand_to = (map { sanitize_address($_) } @expand_to);
+	@expand_cc = (map { sanitize_address($_) } @expand_cc);
+	@expand_bcc = (map { sanitize_address($_) } @expand_bcc);
+
+	for my $a (@expand_to, @expand_cc, @expand_bcc) {
+		print $a . "\n";
+	}
+
+	exit(1);
+}
+
 ($sender) = expand_aliases($sender) if defined $sender;
 
 # returns 1 if the conflict must be solved using it as a format-patch argument

Re: [PATCH RFC] git-send-email --expand-aliases

[Junio C Hamano]

Alex Chiang <achiang@hp.com> writes:

> I'm an StGit user, and while StGit has its own 'stg mail'
> feature, it doesn't know how to expand email aliases (yet).
>
> Certainly, one way to solve that problem would be to hack stgit
> so that it can parse alias files, but to me, that seems silly
> when git-send-email can already do that.
>
> This patch teaches git-send-email to only expand email addresses
> so that other git porcelains don't have to roll their own mail
> alias parsers.

Certainly, one way to solve that would be to hack _both_ stgit and
send-email so that the former runs the latter _only_ to ask for the
expansion and then send the message out, but to me, that seems silly
when git-send-email can already do both expanding aliases and sending
the message ;-)

If you are changing StGit to call git-send-email anyway, why not arrange
stgit to call git-send-email to send the message out instead, instead of
sending messages on its own?

> I imagine the internal implementation of stg mail to work
> something like:
>
> 	call git-send-email --expand-aliases repeatedly, once for
> 	all the combined --to= args, then for all the combined --cc= args,
> 	and finally for all the combined --bcc= args (all passed
> 	to stg mail), read from stdout until EOF

I imagine the internal implementation of stg mail would work something
like:

    prepare messages to send out
    call git-send-email and have it send them

What am I missing?

Re: [PATCH RFC] git-send-email --expand-aliases

[Alex Chiang]

* Junio C Hamano <gitster@pobox.com>:
> Alex Chiang <achiang@hp.com> writes:
> 
> > I'm an StGit user, and while StGit has its own 'stg mail'
> > feature, it doesn't know how to expand email aliases (yet).
> >
> > Certainly, one way to solve that problem would be to hack stgit
> > so that it can parse alias files, but to me, that seems silly
> > when git-send-email can already do that.
> >
> > This patch teaches git-send-email to only expand email addresses
> > so that other git porcelains don't have to roll their own mail
> > alias parsers.
> 
> Certainly, one way to solve that would be to hack _both_ stgit and
> send-email so that the former runs the latter _only_ to ask for the
> expansion and then send the message out, but to me, that seems silly
> when git-send-email can already do both expanding aliases and sending
> the message ;-)
> 
> If you are changing StGit to call git-send-email anyway, why not arrange
> stgit to call git-send-email to send the message out instead, instead of
> sending messages on its own?

Yeah, I thought about that as I was poking around further in
StGit to figure out how it would be calling git-send-email. ;)

> > I imagine the internal implementation of stg mail to work
> > something like:
> >
> > 	call git-send-email --expand-aliases repeatedly, once for
> > 	all the combined --to= args, then for all the combined --cc= args,
> > 	and finally for all the combined --bcc= args (all passed
> > 	to stg mail), read from stdout until EOF
> 
> I imagine the internal implementation of stg mail would work something
> like:
> 
>     prepare messages to send out
>     call git-send-email and have it send them
> 
> What am I missing?

My lack of familiarity with StGit internals. ;)

Your suggestion is much better. I'll take a closer look at StGit
and see how feasible it is.

Unless Catalin has strong objections?

Thanks,
/ac

Re: [PATCH RFC] git-send-email --expand-aliases

[Karl Wiberg]

On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang <achiang@hp.com> wrote:

> * Junio C Hamano <gitster@pobox.com>:
>
> > If you are changing StGit to call git-send-email anyway, why not
> > arrange stgit to call git-send-email to send the message out
> > instead, instead of sending messages on its own?
>
> Yeah, I thought about that as I was poking around further in StGit
> to figure out how it would be calling git-send-email. ;)
>
> > I imagine the internal implementation of stg mail would work
> > something like:
> >
> >     prepare messages to send out
> >     call git-send-email and have it send them
> >
> > What am I missing?
>
> My lack of familiarity with StGit internals. ;)
>
> Your suggestion is much better. I'll take a closer look at StGit and
> see how feasible it is.
>
> Unless Catalin has strong objections?

I think that sounds like a splendid idea. It would be interesting to
see just how thin a wrapper around git send-email (and format-patch)
stg mail could become, without sacrificing features anyone actually
uses. The main complication could be stg mail's templates.

Catalin, how wedded are you to those? ;-)

-- 
Karl Wiberg, kha@treskal.com
   subrabbit.wordpress.com
   www.treskal.com/kalle

Re: [PATCH RFC] git-send-email --expand-aliases

[Junio C Hamano]

Karl Wiberg <kha@treskal.com> writes:

> I think that sounds like a splendid idea. It would be interesting to
> see just how thin a wrapper around git send-email (and format-patch)
> stg mail could become, without sacrificing features anyone actually
> uses. The main complication could be stg mail's templates.

Why do you even need to run format-patch?  If stg mail supports a good
templates to prepare message files, it would be natural to keep using that
to prepare message files.

Re: [PATCH RFC] git-send-email --expand-aliases

[Karl Wiberg]

On Tue, Nov 24, 2009 at 8:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Karl Wiberg <kha@treskal.com> writes:
>
>> I think that sounds like a splendid idea. It would be interesting to
>> see just how thin a wrapper around git send-email (and format-patch)
>> stg mail could become, without sacrificing features anyone actually
>> uses. The main complication could be stg mail's templates.
>
> Why do you even need to run format-patch?  If stg mail supports a good
> templates to prepare message files, it would be natural to keep using that
> to prepare message files.

The only thing stg mail _really_ needs to do, strictly speaking, is to
be git send-email with an easy way to specify a patch, or a range of
patches, to send. Anything above and beyond that is functionality that
we have to write and maintain without the help of the larger git
community, and which won't be of use to said community for no good
reason. Take the template system for cover letters and patches, for
example: there's no reason why it couldn't be part of the git tools,
and if it had been, it would have had many more users and much more
developer love.

It's a question of deciding in which areas the benefits of doing it
ourselves are worth the cost, and where it's better to let git do the
job for us. And of recognizing that StGit is old enough that tradeoffs
that were worth it when git was not as mature and featureful as today
might be worth reconsidering from time to time.

(Alex: Sorry if I'm making a big deal out of this. Just because
rewriting stg mail entirely in terms of the git tools might be
_possible_ doesn't mean that just a few steps in that direction
wouldn't be worthwhile. But I thought I should raise the possibility.)

-- 
Karl Wiberg, kha@treskal.com
   subrabbit.wordpress.com
   www.treskal.com/kalle

Re: [PATCH RFC] git-send-email --expand-aliases

[Catalin Marinas]

2009/11/24 Karl Wiberg <kha@treskal.com>:
> On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang <achiang@hp.com> wrote:
>
>> * Junio C Hamano <gitster@pobox.com>:
>>
>> > If you are changing StGit to call git-send-email anyway, why not
>> > arrange stgit to call git-send-email to send the message out
>> > instead, instead of sending messages on its own?
>>
>> Yeah, I thought about that as I was poking around further in StGit
>> to figure out how it would be calling git-send-email. ;)
>>
>> > I imagine the internal implementation of stg mail would work
>> > something like:
>> >
>> >     prepare messages to send out
>> >     call git-send-email and have it send them
>> >
>> > What am I missing?
>>
>> My lack of familiarity with StGit internals. ;)
>>
>> Your suggestion is much better. I'll take a closer look at StGit and
>> see how feasible it is.
>>
>> Unless Catalin has strong objections?
>
> I think that sounds like a splendid idea. It would be interesting to
> see just how thin a wrapper around git send-email (and format-patch)
> stg mail could become, without sacrificing features anyone actually
> uses. The main complication could be stg mail's templates.
>
> Catalin, how wedded are you to those? ;-)

Historically, I think "stg mail" was implemented before git-send-email
existed. It was also a good way to check who's using stgit for sending
patches :-) (the message-id).

I use templates to send patches to the ARM Linux gatekeeper via a
patch management system which only accepts patches formatted in a
certain way (things improved a bit recently and the format was
relaxed). But I find myself mostly sending pull requests these days,
so that's not a critical feature for me.

If there are no other users of the stg mail templates, I'm happy to
let them go. Otherwise, we can replace the sendmail with
git-send-email in stgit.

It seems that git-format-patch and git-send-email have all the
features stgit has. We would need to keep some of the interactive
options like --edit-cover and --edit-patches since we use
git-format-patch and git-send-email in one go.

-- 
Catalin

Re: [PATCH RFC] git-send-email --expand-aliases

[Alex Chiang]

* Catalin Marinas <catalin.marinas@gmail.com>:
> 2009/11/24 Karl Wiberg <kha@treskal.com>:
> > On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang <achiang@hp.com> wrote:
> >> * Junio C Hamano <gitster@pobox.com>:
> >> > I imagine the internal implementation of stg mail would work
> >> > something like:
> >> >
> >> >     prepare messages to send out
> >> >     call git-send-email and have it send them
> >> >
> >> > What am I missing?
> >>
> >> Your suggestion is much better. I'll take a closer look at StGit and
> >> see how feasible it is.
> >>
> >> Unless Catalin has strong objections?
> >
> > I think that sounds like a splendid idea. It would be interesting to
> > see just how thin a wrapper around git send-email (and format-patch)
> > stg mail could become, without sacrificing features anyone actually
> > uses. The main complication could be stg mail's templates.
> >
> > Catalin, how wedded are you to those? ;-)
> 
> Historically, I think "stg mail" was implemented before git-send-email
> existed. It was also a good way to check who's using stgit for sending
> patches :-) (the message-id).

Heh, I like looking at that too. ;)
 
> If there are no other users of the stg mail templates, I'm happy to
> let them go. Otherwise, we can replace the sendmail with
> git-send-email in stgit.
> 
> It seems that git-format-patch and git-send-email have all the
> features stgit has. We would need to keep some of the interactive
> options like --edit-cover and --edit-patches since we use
> git-format-patch and git-send-email in one go.

So, is this something you (or Karl) plan on doing? Or should I
take a crack at it?

I don't mind doing the work, but it will definitely take me
longer than it would take you.

All I was doing was trying to get stg mail to understand my mutt
aliases. ;)

Thanks,
/ac

Re: [PATCH RFC] git-send-email --expand-aliases

[Karl Wiberg]

On Tue, Nov 24, 2009 at 7:46 PM, Alex Chiang <achiang@hp.com> wrote:

> * Catalin Marinas <catalin.marinas@gmail.com>:
>
> > If there are no other users of the stg mail templates, I'm happy
> > to let them go. Otherwise, we can replace the sendmail with
> > git-send-email in stgit.
> >
> > It seems that git-format-patch and git-send-email have all the
> > features stgit has. We would need to keep some of the interactive
> > options like --edit-cover and --edit-patches since we use
> > git-format-patch and git-send-email in one go.
>
> So, is this something you (or Karl) plan on doing? Or should I take
> a crack at it?

I wasn't planning to do it, at least. I haven't had much time for
StGit lately, but when I do there are other things I was planning to
fix before this.

If you feel like trying, please go ahead. I'll be happy to assist.

> I don't mind doing the work, but it will definitely take me longer
> than it would take you.
>
> All I was doing was trying to get stg mail to understand my mutt
> aliases. ;)

Yeah, sorry about that. ;-)

Seriously, though, doing just what you started out wanting to do would
be fine too. If you decide to do the larger project, it shouldn't be
because we made you feel you had to.

-- 
Karl Wiberg, kha@treskal.com
   subrabbit.wordpress.com
   www.treskal.com/kalle