{"thread":{"id":"21730","subject":"[PATCH RFC] git-send-email --expand-aliases","startedAt":"2009-11-23T22:16:28Z","lastAt":"2009-11-24T19:08:13Z","messageCount":9,"participants":["Alex Chiang","Junio C Hamano","Karl Wiberg","Catalin Marinas"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"128205","messageId":"20091123221628.GE26810@ldl.fc.hp.com","threadId":"21730","inReplyTo":null,"subject":"[PATCH RFC] git-send-email --expand-aliases","fromName":"Alex Chiang","fromEmail":"achiang@hp.com","sentAt":"2009-11-23T22:16:28Z","receivedAt":"2009-11-23T22:16:28Z","isPatch":true,"sender":{"key":"achiang@hp.com","avatar":null},"body":"I'm an StGit user, and while StGit has its own 'stg mail'\nfeature, it doesn't know how to expand email aliases (yet).\n\nCertainly, one way to solve that problem would be to hack stgit\nso that it can parse alias files, but to me, that seems silly\nwhen git-send-email can already do that.\n\nThis patch teaches git-send-email to only expand email addresses\nso that other git porcelains don't have to roll their own mail\nalias parsers.\n\nI imagine the internal implementation of stg mail to work\nsomething like:\n\n\tcall git-send-email --expand-aliases repeatedly, once for\n\tall the combined --to= args, then for all the combined --cc= args,\n\tand finally for all the combined --bcc= args (all passed\n\tto stg mail), read from stdout until EOF\n\nThat API is a little ugly, requiring 3 calls to git-send-email\nfor each class of recipient (to, cc, bcc).\n\nThe other interface that I thought of would be to have\ngit-send-email print a heading like:\n\n\tTO\n\t\n\t\n\tCC\n\t\n\tBCC\n\t\n\nBut, that requires more parsing in the porcelain. Requiring a\ncall to git-send-email for each class of recipient seems like a\nreasonable interface for what will presumably be an API only used\nin an automated manner by a porcelain like stg (and possibly\nguilt?).\n\nI haven't patched stg yet, wanted to see what the feedback on\nthis RFC patch was first. If folks are receptive, I can send a\nfuller patch with expanded help text, etc.\n\nThanks,\n/ac\n\n---\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex a0279de..ac34bec 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -79,6 +79,7 @@ git send-email [options] \n auto, cc, compose, always, or never.\n --quiet * Output one line of info per email.\n --dry-run * Don't actually send the emails.\n+ --expand-aliases * Expands email aliases only and exits\n --[no-]validate * Perform patch sanity checks. Default on.\n --[no-]format-patch * understand any non optional arguments as\n `git format-patch` ones.\n@@ -156,7 +157,7 @@ if ($@) {\n }\n \n # Behavior modification variables\n-my ($quiet, $dry_run) = (0, 0);\n+my ($quiet, $dry_run, $expand_aliases_only) = (0, 0, 0);\n my $format_patch;\n my $compose_filename;\n \n@@ -263,6 +264,7 @@ my $rc = GetOptions(\"sender|from=s\" => \\$sender,\n \t\t \"suppress-cc=s\" => \\@suppress_cc,\n \t\t \"signed-off-cc|signed-off-by-cc!\" => \\$signed_off_by_cc,\n \t\t \"confirm=s\" => \\$confirm,\n+\t\t \"expand-aliases\" => \\$expand_aliases_only,\n \t\t \"dry-run\" => \\$dry_run,\n \t\t \"envelope-sender=s\" => \\$envelope_sender,\n \t\t \"thread!\" => \\$thread,\n@@ -441,6 +443,22 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {\n \t}\n }\n \n+if ($expand_aliases_only) {\n+\tmy @expand_to = expand_aliases(@to);\n+\tmy @expand_cc = expand_aliases(@initial_cc);\n+\tmy @expand_bcc = expand_aliases(@bcclist);\n+\n+\t@expand_to = (map { sanitize_address($_) } @expand_to);\n+\t@expand_cc = (map { sanitize_address($_) } @expand_cc);\n+\t@expand_bcc = (map { sanitize_address($_) } @expand_bcc);\n+\n+\tfor my $a (@expand_to, @expand_cc, @expand_bcc) {\n+\t\tprint $a . \"\\n\";\n+\t}\n+\n+\texit(1);\n+}\n+\n ($sender) = expand_aliases($sender) if defined $sender;\n \n # returns 1 if the conflict must be solved using it as a format-patch argument\n"},{"id":"128216","messageId":"7v6390sqhz.fsf@alter.siamese.dyndns.org","threadId":"21730","inReplyTo":"20091123221628.GE26810@ldl.fc.hp.com","subject":"Re: [PATCH RFC] git-send-email --expand-aliases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-24T00:42:00Z","receivedAt":"2009-11-24T00:42:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Chiang writes:\n\n> I'm an StGit user, and while StGit has its own 'stg mail'\n> feature, it doesn't know how to expand email aliases (yet).\n>\n> Certainly, one way to solve that problem would be to hack stgit\n> so that it can parse alias files, but to me, that seems silly\n> when git-send-email can already do that.\n>\n> This patch teaches git-send-email to only expand email addresses\n> so that other git porcelains don't have to roll their own mail\n> alias parsers.\n\nCertainly, one way to solve that would be to hack _both_ stgit and\nsend-email so that the former runs the latter _only_ to ask for the\nexpansion and then send the message out, but to me, that seems silly\nwhen git-send-email can already do both expanding aliases and sending\nthe message ;-)\n\nIf you are changing StGit to call git-send-email anyway, why not arrange\nstgit to call git-send-email to send the message out instead, instead of\nsending messages on its own?\n\n> I imagine the internal implementation of stg mail to work\n> something like:\n>\n> \tcall git-send-email --expand-aliases repeatedly, once for\n> \tall the combined --to= args, then for all the combined --cc= args,\n> \tand finally for all the combined --bcc= args (all passed\n> \tto stg mail), read from stdout until EOF\n\nI imagine the internal implementation of stg mail would work something\nlike:\n\n prepare messages to send out\n call git-send-email and have it send them\n\nWhat am I missing?\n"},{"id":"128217","messageId":"20091124004554.GA27643@ldl.fc.hp.com","threadId":"21730","inReplyTo":"7v6390sqhz.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC] git-send-email --expand-aliases","fromName":"Alex Chiang","fromEmail":"achiang@hp.com","sentAt":"2009-11-24T00:45:54Z","receivedAt":"2009-11-24T00:45:54Z","isPatch":true,"sender":{"key":"achiang@hp.com","avatar":null},"body":"* Junio C Hamano :\n> Alex Chiang writes:\n> \n> > I'm an StGit user, and while StGit has its own 'stg mail'\n> > feature, it doesn't know how to expand email aliases (yet).\n> >\n> > Certainly, one way to solve that problem would be to hack stgit\n> > so that it can parse alias files, but to me, that seems silly\n> > when git-send-email can already do that.\n> >\n> > This patch teaches git-send-email to only expand email addresses\n> > so that other git porcelains don't have to roll their own mail\n> > alias parsers.\n> \n> Certainly, one way to solve that would be to hack _both_ stgit and\n> send-email so that the former runs the latter _only_ to ask for the\n> expansion and then send the message out, but to me, that seems silly\n> when git-send-email can already do both expanding aliases and sending\n> the message ;-)\n> \n> If you are changing StGit to call git-send-email anyway, why not arrange\n> stgit to call git-send-email to send the message out instead, instead of\n> sending messages on its own?\n\nYeah, I thought about that as I was poking around further in\nStGit to figure out how it would be calling git-send-email. ;)\n\n> > I imagine the internal implementation of stg mail to work\n> > something like:\n> >\n> > \tcall git-send-email --expand-aliases repeatedly, once for\n> > \tall the combined --to= args, then for all the combined --cc= args,\n> > \tand finally for all the combined --bcc= args (all passed\n> > \tto stg mail), read from stdout until EOF\n> \n> I imagine the internal implementation of stg mail would work something\n> like:\n> \n> prepare messages to send out\n> call git-send-email and have it send them\n> \n> What am I missing?\n\nMy lack of familiarity with StGit internals. ;)\n\nYour suggestion is much better. I'll take a closer look at StGit\nand see how feasible it is.\n\nUnless Catalin has strong objections?\n\nThanks,\n/ac\n"},{"id":"128231","messageId":"b8197bcb0911232312l251dfbc9va671388cfb7fe57b@mail.gmail.com","threadId":"21730","inReplyTo":"20091124004554.GA27643@ldl.fc.hp.com","subject":"Re: [PATCH RFC] git-send-email --expand-aliases","fromName":"Karl Wiberg","fromEmail":"kha@treskal.com","sentAt":"2009-11-24T07:12:17Z","receivedAt":"2009-11-24T07:12:17Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang wrote:\n\n> * Junio C Hamano :\n>\n> > If you are changing StGit to call git-send-email anyway, why not\n> > arrange stgit to call git-send-email to send the message out\n> > instead, instead of sending messages on its own?\n>\n> Yeah, I thought about that as I was poking around further in StGit\n> to figure out how it would be calling git-send-email. ;)\n>\n> > I imagine the internal implementation of stg mail would work\n> > something like:\n> >\n> >     prepare messages to send out\n> >     call git-send-email and have it send them\n> >\n> > What am I missing?\n>\n> My lack of familiarity with StGit internals. ;)\n>\n> Your suggestion is much better. I'll take a closer look at StGit and\n> see how feasible it is.\n>\n> Unless Catalin has strong objections?\n\nI think that sounds like a splendid idea. It would be interesting to\nsee just how thin a wrapper around git send-email (and format-patch)\nstg mail could become, without sacrificing features anyone actually\nuses. The main complication could be stg mail's templates.\n\nCatalin, how wedded are you to those? ;-)\n\n-- \nKarl Wiberg, kha@treskal.com\n subrabbit.wordpress.com\n www.treskal.com/kalle\n"},{"id":"128233","messageId":"7vfx84jsef.fsf@alter.siamese.dyndns.org","threadId":"21730","inReplyTo":"b8197bcb0911232312l251dfbc9va671388cfb7fe57b@mail.gmail.com","subject":"Re: [PATCH RFC] git-send-email --expand-aliases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-24T07:25:44Z","receivedAt":"2009-11-24T07:25:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karl Wiberg writes:\n\n> I think that sounds like a splendid idea. It would be interesting to\n> see just how thin a wrapper around git send-email (and format-patch)\n> stg mail could become, without sacrificing features anyone actually\n> uses. The main complication could be stg mail's templates.\n\nWhy do you even need to run format-patch? If stg mail supports a good\ntemplates to prepare message files, it would be natural to keep using that\nto prepare message files.\n"},{"id":"128236","messageId":"b8197bcb0911232352v438c721at44601c608f4a7afe@mail.gmail.com","threadId":"21730","inReplyTo":"7vfx84jsef.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC] git-send-email --expand-aliases","fromName":"Karl Wiberg","fromEmail":"kha@treskal.com","sentAt":"2009-11-24T07:52:29Z","receivedAt":"2009-11-24T07:52:29Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On Tue, Nov 24, 2009 at 8:25 AM, Junio C Hamano wrote:\n> Karl Wiberg writes:\n>\n>> I think that sounds like a splendid idea. It would be interesting to\n>> see just how thin a wrapper around git send-email (and format-patch)\n>> stg mail could become, without sacrificing features anyone actually\n>> uses. The main complication could be stg mail's templates.\n>\n> Why do you even need to run format-patch?  If stg mail supports a good\n> templates to prepare message files, it would be natural to keep using that\n> to prepare message files.\n\nThe only thing stg mail _really_ needs to do, strictly speaking, is to\nbe git send-email with an easy way to specify a patch, or a range of\npatches, to send. Anything above and beyond that is functionality that\nwe have to write and maintain without the help of the larger git\ncommunity, and which won't be of use to said community for no good\nreason. Take the template system for cover letters and patches, for\nexample: there's no reason why it couldn't be part of the git tools,\nand if it had been, it would have had many more users and much more\ndeveloper love.\n\nIt's a question of deciding in which areas the benefits of doing it\nourselves are worth the cost, and where it's better to let git do the\njob for us. And of recognizing that StGit is old enough that tradeoffs\nthat were worth it when git was not as mature and featureful as today\nmight be worth reconsidering from time to time.\n\n(Alex: Sorry if I'm making a big deal out of this. Just because\nrewriting stg mail entirely in terms of the git tools might be\n_possible_ doesn't mean that just a few steps in that direction\nwouldn't be worthwhile. But I thought I should raise the possibility.)\n\n-- \nKarl Wiberg, kha@treskal.com\n subrabbit.wordpress.com\n www.treskal.com/kalle\n"},{"id":"128240","messageId":"b0943d9e0911240243m13730f0bw34f2f18cf41f9079@mail.gmail.com","threadId":"21730","inReplyTo":"b8197bcb0911232312l251dfbc9va671388cfb7fe57b@mail.gmail.com","subject":"Re: [PATCH RFC] git-send-email --expand-aliases","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2009-11-24T10:43:44Z","receivedAt":"2009-11-24T10:43:44Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"2009/11/24 Karl Wiberg :\n> On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang wrote:\n>\n>> * Junio C Hamano :\n>>\n>> > If you are changing StGit to call git-send-email anyway, why not\n>> > arrange stgit to call git-send-email to send the message out\n>> > instead, instead of sending messages on its own?\n>>\n>> Yeah, I thought about that as I was poking around further in StGit\n>> to figure out how it would be calling git-send-email. ;)\n>>\n>> > I imagine the internal implementation of stg mail would work\n>> > something like:\n>> >\n>> >     prepare messages to send out\n>> >     call git-send-email and have it send them\n>> >\n>> > What am I missing?\n>>\n>> My lack of familiarity with StGit internals. ;)\n>>\n>> Your suggestion is much better. I'll take a closer look at StGit and\n>> see how feasible it is.\n>>\n>> Unless Catalin has strong objections?\n>\n> I think that sounds like a splendid idea. It would be interesting to\n> see just how thin a wrapper around git send-email (and format-patch)\n> stg mail could become, without sacrificing features anyone actually\n> uses. The main complication could be stg mail's templates.\n>\n> Catalin, how wedded are you to those? ;-)\n\nHistorically, I think \"stg mail\" was implemented before git-send-email\nexisted. It was also a good way to check who's using stgit for sending\npatches :-) (the message-id).\n\nI use templates to send patches to the ARM Linux gatekeeper via a\npatch management system which only accepts patches formatted in a\ncertain way (things improved a bit recently and the format was\nrelaxed). But I find myself mostly sending pull requests these days,\nso that's not a critical feature for me.\n\nIf there are no other users of the stg mail templates, I'm happy to\nlet them go. Otherwise, we can replace the sendmail with\ngit-send-email in stgit.\n\nIt seems that git-format-patch and git-send-email have all the\nfeatures stgit has. We would need to keep some of the interactive\noptions like --edit-cover and --edit-patches since we use\ngit-format-patch and git-send-email in one go.\n\n-- \nCatalin\n"},{"id":"128254","messageId":"20091124184629.GB27418@ldl.fc.hp.com","threadId":"21730","inReplyTo":"b0943d9e0911240243m13730f0bw34f2f18cf41f9079@mail.gmail.com","subject":"Re: [PATCH RFC] git-send-email --expand-aliases","fromName":"Alex Chiang","fromEmail":"achiang@hp.com","sentAt":"2009-11-24T18:46:29Z","receivedAt":"2009-11-24T18:46:29Z","isPatch":true,"sender":{"key":"achiang@hp.com","avatar":null},"body":"* Catalin Marinas :\n> 2009/11/24 Karl Wiberg :\n> > On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang wrote:\n> >> * Junio C Hamano :\n> >> > I imagine the internal implementation of stg mail would work\n> >> > something like:\n> >> >\n> >> >     prepare messages to send out\n> >> >     call git-send-email and have it send them\n> >> >\n> >> > What am I missing?\n> >>\n> >> Your suggestion is much better. I'll take a closer look at StGit and\n> >> see how feasible it is.\n> >>\n> >> Unless Catalin has strong objections?\n> >\n> > I think that sounds like a splendid idea. It would be interesting to\n> > see just how thin a wrapper around git send-email (and format-patch)\n> > stg mail could become, without sacrificing features anyone actually\n> > uses. The main complication could be stg mail's templates.\n> >\n> > Catalin, how wedded are you to those? ;-)\n> \n> Historically, I think \"stg mail\" was implemented before git-send-email\n> existed. It was also a good way to check who's using stgit for sending\n> patches :-) (the message-id).\n\nHeh, I like looking at that too. ;)\n \n> If there are no other users of the stg mail templates, I'm happy to\n> let them go. Otherwise, we can replace the sendmail with\n> git-send-email in stgit.\n> \n> It seems that git-format-patch and git-send-email have all the\n> features stgit has. We would need to keep some of the interactive\n> options like --edit-cover and --edit-patches since we use\n> git-format-patch and git-send-email in one go.\n\nSo, is this something you (or Karl) plan on doing? Or should I\ntake a crack at it?\n\nI don't mind doing the work, but it will definitely take me\nlonger than it would take you.\n\nAll I was doing was trying to get stg mail to understand my mutt\naliases. ;)\n\nThanks,\n/ac\n"},{"id":"128257","messageId":"b8197bcb0911241108mc0d6297h48d3c7bc69acc8e5@mail.gmail.com","threadId":"21730","inReplyTo":"20091124184629.GB27418@ldl.fc.hp.com","subject":"Re: [PATCH RFC] git-send-email --expand-aliases","fromName":"Karl Wiberg","fromEmail":"kha@treskal.com","sentAt":"2009-11-24T19:08:13Z","receivedAt":"2009-11-24T19:08:13Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On Tue, Nov 24, 2009 at 7:46 PM, Alex Chiang wrote:\n\n> * Catalin Marinas :\n>\n> > If there are no other users of the stg mail templates, I'm happy\n> > to let them go. Otherwise, we can replace the sendmail with\n> > git-send-email in stgit.\n> >\n> > It seems that git-format-patch and git-send-email have all the\n> > features stgit has. We would need to keep some of the interactive\n> > options like --edit-cover and --edit-patches since we use\n> > git-format-patch and git-send-email in one go.\n>\n> So, is this something you (or Karl) plan on doing? Or should I take\n> a crack at it?\n\nI wasn't planning to do it, at least. I haven't had much time for\nStGit lately, but when I do there are other things I was planning to\nfix before this.\n\nIf you feel like trying, please go ahead. I'll be happy to assist.\n\n> I don't mind doing the work, but it will definitely take me longer\n> than it would take you.\n>\n> All I was doing was trying to get stg mail to understand my mutt\n> aliases. ;)\n\nYeah, sorry about that. ;-)\n\nSeriously, though, doing just what you started out wanting to do would\nbe fine too. If you decide to do the larger project, it shouldn't be\nbecause we made you feel you had to.\n\n-- \nKarl Wiberg, kha@treskal.com\n subrabbit.wordpress.com\n www.treskal.com/kalle\n"}]}