threads / rfc / 21730

RFC patchgit-send-email --expand-aliases

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

## tl;dr

9 messages between Nov 23, 2009 and Nov 24, 2009. Diffs are folded; open one to read it.

replies: 8people: 4as markdown or json

Alex Chiang· Nov 23, 2009, 22:16 UTC · lore

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

---
Show changes to git-send-email.perl +19 −1
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
Junio C Hamano· Nov 24, 2009, 00:42 UTC · re: Alex Chiang · lore

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

Alex Chiang <achiang@hp.com> writes:
Show 10 quoted lines
> 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?

Show 7 quoted lines
> 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?
Alex Chiang· Nov 24, 2009, 00:45 UTC · re: Junio C Hamano · lore

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

* Junio C Hamano <gitster@pobox.com>:
Show 22 quoted lines
> 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. ;)

Show 15 quoted lines
> > 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

Karl Wiberg· Nov 24, 2009, 07:12 UTC · re: Alex Chiang · lore

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

On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang <achiang@hp.com> wrote:
Show 23 quoted lines
> * 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
Junio C Hamano· Nov 24, 2009, 07:25 UTC · re: Karl Wiberg · lore

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

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.

Karl Wiberg· Nov 24, 2009, 07:52 UTC · re: Junio C Hamano · lore

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

On Tue, Nov 24, 2009 at 8:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> 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
Catalin Marinas· Nov 24, 2009, 10:43 UTC · re: Karl Wiberg · lore

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

2009/11/24 Karl Wiberg <kha@treskal.com>:
Show 32 quoted lines
> 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
Alex Chiang· Nov 24, 2009, 18:46 UTC · re: Catalin Marinas · lore

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

* Catalin Marinas <catalin.marinas@gmail.com>:
Show 26 quoted lines
> 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. ;)
 
Show 8 quoted lines
> 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

Karl Wiberg· Nov 24, 2009, 19:08 UTC · re: Alex Chiang · lore

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

On Tue, Nov 24, 2009 at 7:46 PM, Alex Chiang <achiang@hp.com> wrote:
Show 13 quoted lines
> * 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.
Show 5 quoted lines
> 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

← back to recent threads