view release on metacpan or  search on metacpan

t/samples/plasmastrum.xml  view on Meta::CPAN

  <p><cite><a href="http://blog.feedbin.com/2014/03/11/feedbins-first-year/" title="Feedbin’s First Year">Ben Ubois</a></cite>:</p>
  <blockquote cite="http://blog.feedbin.com/2014/03/11/feedbins-first-year/"><p><abbr title="Really Simple Syndication">RSS</abbr> is one of the last holdouts of a more open web and it’s been gratifying to see that there’s enough interest in it t...
  <p>It used to be that the web was a platform – not just its technical underpinnings, but the content itself that was on the web. Then it was gradually reduced to a substrate for supporting a bunch of oil rigs, each isolated. Or so it seems; it is...
</div></content><category scheme="http://plasmasturm.org/" term="seen" label="Seen"/></entry><entry><title>Sensible Git mail for the occasional user</title><summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">A convenient manual <code>git ...
  <p>This entry is mostly for my own benefit, since – being an occasional user – I keep having to figure this out from scratch. What I was aiming for is a workflow that gives me both convenience and full control.</p>
  <p>I don’t like <code>git send-email</code>. The command assembles and sends mail all in one go, so you have to know what it will do blindly. Running <code>git format-patch</code> manually first only helps a little, since <code>git send-email</co...
  <p>Unfortunately the patchmail I do send every once in a while goes to places with many subscribers, and I’m unwilling to rattle their inboxes with my (repeat!) learning process. I want to be sure I’ll send exactly the mail I mean to, on the ve...
  <p>I also have <a href="http://msmtp.sourceforge.net/">msmtp</a> set up on my home server with all the details of my <abbr title="Simple Mail Transfer Protocol">SMTP</abbr> accounts and really don’t want to maintain another copy of that informati...
  <p>So for me, the answer is to avoid <code>git send-email</code> entirely.</p>
  <p>The key realisation is that once a mail is properly formatted,  sending it is nothing more than piping it to <code>/usr/bin/sendmail</code> (or whatever equivalent you employ) – so you actually need only <code>git format-patch</code>.</p>
  <p>There is just one little wrinkle to take care of: the “<code>From </code>” line it generates needs to be removed before its output can be piped to <code>sendmail</code>. This is easily done using <code>formail</code>, which can also split mb...
  <p>Bottom line, this replicates <code>git send-email</code>:</p>
  <pre><code class="ft-sh">git format-patch --stdout <i>origin</i> | formail -I 'From ' -s sendmail -t</code></pre>
  <p>(Obviously, you season it with <code>--to <i>whomever@example.net</i></code> <abbr title="et ceterea">etc.</abbr> to taste.)</p>
  <p>Here, <code>git format-patch</code> produces an mbox-format mail folder, which <code>formail</code> splits into individual mails (“<code>-s …</code>”), and for each mail, deletes the <code>From</code> line (“<code>-I 'From '</code>”) a...
  <p>But note what I gained here:</p>
  <p>I can omit the pipe.</p>
  <p>That allows me to inspect the exact mail that will be sent. In fact, if you don’t pipe the output anywhere, Git will invoke the pager for you and even highlight the diffs within the attachments: excellent. Then if I’m satisfied, I add the pi...
  <p>And if there was a cover letter I needed to edit? Then I just pipe to a file first, before piping to <code>formail</code>. In between those steps, I can edit the file – whether in Vim directly, or using <code>mutt -f <i>mbox</i></code>.</p>
  <p>Of course, this isn’t necessarily for everyone. You need a machine with procmail installed (for <code>formail</code>) and a <code>sendmail</code>-compatible <abbr title="Mail Transport Agent">MTA</abbr> set up. You also need to be comfortable ...
  <p>But it works for me. Sending patchmail is no longer something I put off.</p>