git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [WIP-PATCH 1/2] send-email: create email parser subroutine

From
EWEric Wong <e@80x24.org>
Date
Jun 2, 2016, 19:58 UTC
Message-ID
<20160602195855.GA17627@dcvr.yhbt.net>
In-Reply-To
<9535d962-5479-5a13-472e-cd558ef163e0@grenoble-inp.org>
Samuel GROOT <samuel.groot@grenoble-inp.org> wrote:
Show 36 quoted lines
> On 05/29/2016 01:33 AM, Eric Wong wrote:
> >Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> >>Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> >>
> >>>Parsing and processing in send-email is done in the same loop.
> >>>
> >>>To make the code more maintainable, we create two subroutines:
> >>>- `parse_email` to separate header and body
> >>>- `parse_header` to retrieve data from header
> >>
> >>These routines are not specific to git send-email, nor to Git.
> >>
> >>Does it make sense to use an external library, like
> >>http://search.cpan.org/~rjbs/Email-Simple-2.210/lib/Email/Simple.pm ,
> >>either by depending on it, or by copying it in Git's source tree ?
> >
> >That might be overkill and increase installation/maintenance
> >burden.  Bundling it would probably be problematic to distros,
> >too.
> 
> We have 5 solutions here:
> 
>   1. Make a new dependence to Email::Simple.
> 
>   2. Bundle Email::Simple in Git's source tree.
> 
>   3. Use Email::Simple if installed, else use our library.
> 
>   4. Making our own email parser library.
> 
>   5. Duplicate parser loop as we did for our patch to implement
>      `--quote-email` as proposed in $gmane/295772 .
> 
> Obviously, option (5) is the easiest one for us, but it leaves refactoring
> for later, and option (1) is also easier but adds a new dependence which is
> not that good.

I would go with (5) for now and leave (4) for later (which might just be moving the function to a new file).

Show 7 quoted lines
> Since our project ends next week, we might not have enough time to finish
> developing a custom parser API so (4) is not a viable option for now but
> could be done in the future.
> 
> We could consider bundling Email::Simple as the best option, as it's
> developed since 2003 and might be safer to use than anything we could write
> in several weeks.

In an ideal world, (1) would be nice. But (IMHO) git-send-email should remain installable on non-ideal systems which do not provide Email::Simple as a package.

(2) would probably be non-ideal for distro maintainers (+Cc: Jonathan for opinions), and (3) is the most complex and difficult-to-support.

Previous: Samuel GROOTNext: Samuel GROOT
Message 9 of 18 in “send-email: refactor the email parser loop”
  1. 0/2 send-email: refactor the email parser loopSamuel GROOT, May 27, 2016
  2. 1/2 send-email: create email parser subroutineSamuel GROOT, May 27, 2016
  3. Matthieu MoyMay 28, 2016
  4. Eric WongMay 28, 2016
  5. Samuel GROOTMay 29, 2016
  6. Matthieu MoyMay 29, 2016
  7. Samuel GROOTMay 30, 2016
  8. Samuel GROOTJun 2, 2016
  9. Eric WongJun 2, 2016
  10. 2/2 send-email: use refactored subroutine to parse patchesSamuel GROOT, May 27, 2016
  11. Eric WongMay 27, 2016
  12. Matthieu MoyMay 28, 2016
  13. Samuel GROOTMay 29, 2016
  14. Matthieu MoyMay 29, 2016
  15. Samuel GROOTMay 30, 2016
  16. Matthieu MoyMay 30, 2016
  17. Samuel GROOTMay 30, 2016
  18. Matthieu MoyMay 30, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.