4 ms·

-M sends daily digests to your users based on git commit messages

32 points by jpadilla_ 15y ago

callmeed 15y ago
This is very nice and solves the exact problem I have. Two questions: - How can I send it to my MailChimp list of beta testers? - Can it be posted to a blog/page (maybe Posterous or Tumblr will accept the email and auto-post)?
- jpadilla_ 15y ago
  Thanks! For now I guess you could export the emails from Mailchimp, separated by commas and add them to the recipients list on -M
civilian 15y ago
What I often have silliness & profanity (in addition to useful information) in my commit messages?
- jpadilla_ 15y ago
  I think we'll do. -M gave us the opportunity to write better commit messages and be careful what exactly we write, since our users would be reading them.
atlbeer 15y ago
Actually, could be a good management tool as well. I could use this on projects to keep track of development efforts without having to have my tech lead write me status updates. I check commit logs whenever I can but, getting it right to me email in a daily digest would be a blessing.
mahmud 15y ago
Software developer community is over-served when it comes to tools and automation. Please, just branch out and help people who aren't programmers. This goes to everyone of you HNers.
- tikhonj 15y ago
  I don't think this is true at all. The developer community might get more attention than everybody else, but this is a good thing: making developers more efficient results in more software for everybody. Besides, most such projects are written to fill a specific need of the author. They would have been written regardless; they are released because of the open-source culture prevalent in the development community. There are so many development tools just because developers are so happy to share. Edit: I'm not sure this particular product is open-source. I'm just commenting on the prevalence of developer tools in general.
  - mahmud 15y ago
    Coding for developers is like being a security guard for the army.
    - eaurouge 15y ago
      Depending on what you code, coding for developers could be like providing ammo to the army, or like building robots for the army, sometimes for free. Except you actually create a cascading effect as better software tools lead to better software, which leads to ... But you already know this, or should.
- jpadilla_ 15y ago
  I don't think its over-served at all. We like to build tools; tools for regular users, and tools for power users. Tools for power users make it easier to build tools for regular users. So Blimp is a tool for your regular user, and -M is a tool to make it easier for us to keep working on Blimp.
dreeves 15y ago
I think this needs a little more human curation. There are too many commit messages that are about internals that users really don't want to know about. Here's what we do: http://blog.beeminder.com/blogdog http://blog.beeminder.com/blogdog In short, we have a special twitter account for User-Visible Improvements (UVIs). We manually look over our commits and task list and tweet on average one UVI per day. EDIT: Also, thanks for making -M availaible! I'm trying it out.
- tikhonj 15y ago
  As another option, couldn't you just include some sort of tag in each commit you want included, when you commit it? Something like "#interesting" at the end of the message. I'm not sure that would be better, but it would be a nice option to consider.
- deleted 15y ago
  [deleted]
- jpadilla_ 15y ago
  That's very interesting! We've been discussing a couple of ways "curating" those commit messages. One way I've thought of doing is to take the commit messages with the highest impact(according to Github: Impact is lines added + lines deleted), still not sure about it. Thanks for the feedback!
- roryokane 15y ago
  One way -M could automate user-visible and non-user-visible improvements is to have separate branches for each type of improvement. -M would email only commits in the UVIs branch. (And the master branch would just merge commits from those two separate branches, and contain no original commits.) This would allow UVIs to be chosen at commit-time, rather than manually right before sending the email. (It would be possible but harder to choose UVIs manually right before sending the email, by editing history so those commits were in the right branch.)
niels 15y ago
We tweet every commit to a private list. Works great and everyone in the company can follow what is going on in dev.
aslakhellesoy 15y ago
This doesn't seem to work for me. I added a post-commit hook to one of my private repos, pushed a couple of commits, and the http://minusm.com/app/repo/ http://minusm.com/app/repo/ page still sayd "Duuude, Go to Github and add the Post-Receive URL..." I haven't received any emails either, even though I pushed commits before the time when it's supposed to mail out commits. Is this only supposed to work for public repos?
- aslakhellesoy 15y ago
  I figured out why it doesn't work. It has nothing to do with private or public repos. It doesn't work for projects that are under an organization. That would be nice to get fixed.

32 points by jpadilla_ 15y ago

This is very nice and solves the exact problem I have. Two questions: - How can I send it to my MailChimp list of beta testers? - Can it be posted to a blog/page (maybe Posterous or Tumblr will accept the email and auto-post)?

jpadilla_ 15y ago
Thanks! For now I guess you could export the emails from Mailchimp, separated by commas and add them to the recipients list on -M

civilian 15y ago

What I often have silliness & profanity (in addition to useful information) in my commit messages?

jpadilla_ 15y ago
I think we'll do. -M gave us the opportunity to write better commit messages and be careful what exactly we write, since our users would be reading them.

atlbeer 15y ago

Actually, could be a good management tool as well. I could use this on projects to keep track of development efforts without having to have my tech lead write me status updates. I check commit logs whenever I can but, getting it right to me email in a daily digest would be a blessing.

mahmud 15y ago

Software developer community is over-served when it comes to tools and automation. Please, just branch out and help people who aren't programmers. This goes to everyone of you HNers.

tikhonj 15y ago
I don't think this is true at all. The developer community might get more attention than everybody else, but this is a good thing: making developers more efficient results in more software for everybody. Besides, most such projects are written to fill a specific need of the author. They would have been written regardless; they are released because of the open-source culture prevalent in the development community. There are so many development tools just because developers are so happy to share. Edit: I'm not sure this particular product is open-source. I'm just commenting on the prevalence of developer tools in general.
- mahmud 15y ago
  Coding for developers is like being a security guard for the army.
  - eaurouge 15y ago
    Depending on what you code, coding for developers could be like providing ammo to the army, or like building robots for the army, sometimes for free. Except you actually create a cascading effect as better software tools lead to better software, which leads to ... But you already know this, or should.
jpadilla_ 15y ago
I don't think its over-served at all. We like to build tools; tools for regular users, and tools for power users. Tools for power users make it easier to build tools for regular users. So Blimp is a tool for your regular user, and -M is a tool to make it easier for us to keep working on Blimp.

dreeves 15y ago

I think this needs a little more human curation. There are too many commit messages that are about internals that users really don't want to know about. Here's what we do: http://blog.beeminder.com/blogdog http://blog.beeminder.com/blogdog In short, we have a special twitter account for User-Visible Improvements (UVIs). We manually look over our commits and task list and tweet on average one UVI per day. EDIT: Also, thanks for making -M availaible! I'm trying it out.

tikhonj 15y ago
As another option, couldn't you just include some sort of tag in each commit you want included, when you commit it? Something like "#interesting" at the end of the message. I'm not sure that would be better, but it would be a nice option to consider.
deleted 15y ago
[deleted]
jpadilla_ 15y ago
That's very interesting! We've been discussing a couple of ways "curating" those commit messages. One way I've thought of doing is to take the commit messages with the highest impact(according to Github: Impact is lines added + lines deleted), still not sure about it. Thanks for the feedback!
roryokane 15y ago
One way -M could automate user-visible and non-user-visible improvements is to have separate branches for each type of improvement. -M would email only commits in the UVIs branch. (And the master branch would just merge commits from those two separate branches, and contain no original commits.) This would allow UVIs to be chosen at commit-time, rather than manually right before sending the email. (It would be possible but harder to choose UVIs manually right before sending the email, by editing history so those commits were in the right branch.)

niels 15y ago

We tweet every commit to a private list. Works great and everyone in the company can follow what is going on in dev.

aslakhellesoy 15y ago

This doesn't seem to work for me. I added a post-commit hook to one of my private repos, pushed a couple of commits, and the http://minusm.com/app/repo/ http://minusm.com/app/repo/ page still sayd "Duuude, Go to Github and add the Post-Receive URL..." I haven't received any emails either, even though I pushed commits before the time when it's supposed to mail out commits. Is this only supposed to work for public repos?

aslakhellesoy 15y ago
I figured out why it doesn't work. It has nothing to do with private or public repos. It doesn't work for projects that are under an organization. That would be nice to get fixed.