From: Junio C Hamano Date: Tue, 24 Nov 2009 00:42:00 GMT Subject: Re: [PATCH RFC] git-send-email --expand-aliases Message-ID: <7v6390sqhz.fsf@alter.siamese.dyndns.org> In-Reply-To: <20091123221628.GE26810@ldl.fc.hp.com> Alex Chiang 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?