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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:47:45

Karl Wiberg [off-list ref] 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

From: Karl Wiberg <hidden>
Date: 2016-06-15 22:47:45

On Tue, Nov 24, 2009 at 8:25 AM, Junio C Hamano [off-list ref] wrote:
Karl Wiberg [off-list ref] writes:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help