From: Karl Wiberg <kha@treskal.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Alex Chiang <achiang@hp.com>,
Catalin Marinas <catalin.marinas@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH RFC] git-send-email --expand-aliases
Date: Tue, 24 Nov 2009 08:52:29 +0100 [thread overview]
Message-ID: <b8197bcb0911232352v438c721at44601c608f4a7afe@mail.gmail.com> (raw)
In-Reply-To: <7vfx84jsef.fsf@alter.siamese.dyndns.org>
On Tue, Nov 24, 2009 at 8:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 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
next prev parent reply other threads:[~2009-11-24 7:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-23 22:16 [PATCH RFC] git-send-email --expand-aliases Alex Chiang
2009-11-24 0:42 ` Junio C Hamano
2009-11-24 0:45 ` Alex Chiang
2009-11-24 7:12 ` Karl Wiberg
2009-11-24 7:25 ` Junio C Hamano
2009-11-24 7:52 ` Karl Wiberg [this message]
2009-11-24 10:43 ` Catalin Marinas
2009-11-24 18:46 ` Alex Chiang
2009-11-24 19:08 ` Karl Wiberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b8197bcb0911232352v438c721at44601c608f4a7afe@mail.gmail.com \
--to=kha@treskal.com \
--cc=achiang@hp.com \
--cc=catalin.marinas@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).