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

Alex Chiang [off-list ref] 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?

* Junio C Hamano [off-list ref]:

Alex Chiang [off-list ref] writes:

quoted

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. ;)

quoted

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

On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang [off-list ref] wrote:

* Junio C Hamano [off-list ref]:

quoted

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. ;)

quoted

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

2009/11/24 Karl Wiberg [off-list ref]:

On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang [off-list ref] wrote:

quoted

* Junio C Hamano [off-list ref]:

quoted

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. ;)

quoted

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

* Catalin Marinas [off-list ref]:

2009/11/24 Karl Wiberg [off-list ref]:

quoted

On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang [off-list ref] wrote:

quoted

* Junio C Hamano [off-list ref]:

quoted

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

On Tue, Nov 24, 2009 at 7:46 PM, Alex Chiang [off-list ref] wrote:

* Catalin Marinas [off-list ref]:

quoted

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