Re: [RFC] ssoma-mda: Use the email subject as the commit message

[Eric Wong <e@80x24.org>]

"W. Trevor King" <wking@tremily.us> wrote:
> This is more interesting than just using 'mda' all the time, but it's
> harder to setup proper quoting around the message without using
> third-party Perl modules (e.g. IPC::Run or String::ShellQuote).  This
> proof-of-concept patch just assumes the subject doesn't contain
> single-quotes (').  This patch also doesn't handle the empty/missing
> subject case, which should probably fall back to '<no subject>' or
> some such.

Right, carelessness here would open us up to command injection.  It
would also need to work with internationalized subjects.  I considered
it for public-inbox-mda; but decided it was not worth the trouble.

> It would also be useful (I think) to set the GIT_AUTHOR_NAME,
> GIT_AUTHOR_EMAIL, and GIT_AUTHOR_DATE environment variables from the
> message header before committing.  I know how to do that using
> Python's subprocess module, but I don't know the Perl incantation.

That's done in public-inbox-mda using

	local $ENV{...} = ...

And more Email::* modules to properly decode various email addresses and
internationalized names.  I wanted to keep ssoma as lean and dumb as
possible.

> Is there any interest in a Python port of ssoma?  The subprocess
> handling in Perl's standard libraries is not my favorite ;).  I expect
> we could handle all of ssoma without leaving Python's standard
> libraries.  For an example of a related Perl -> Python rewrite that I
> just landed, see nmbug [1,2,3].

I think you're the only one who's shown any interest in ssoma at all :)
I would love to have multiple implementations of ssoma and want a Ruby
one, too.  However I don't think using Python/Ruby would increase it's
ease-of-installation or adoption much (and most of my software is Ruby).

Fwiw, the commit subject/message currently has no bearing on the way
ssoma or public-inbox handles the mail data.  So another implementation
is free to use more metadata in the commit message.

I've considered adding fuzzy generation counters to commit messages to
public-inbox to allow easier history traversals; but decided it's
probably better to do in any out-of-band, easily-regenerated store
using sqlite or similar (this may help with adding search support to
the web UI as well).