[plt-dev] One e-mail per commit?

I agree with Eli completely here (except that I keep paper grocery 
lists). If I received that many automated emails, I predict they would 
get procmailed away into a folder never to be seen again.

I vote no to one-email-per-commit.

My ideal form of notification would tell me the committer(s), the 
part(s) of the tree where activity was taking place, the commit 
messages, and a link to the full diff if I want to examine it.... all in 
the first twenty or so lines of the message. (< 20 lines for a typical 
push; pushes with many commits would need more lines, of course). I'm 
disinclined to scroll through long auto-generated emails, so I probably 
only catch the first commit message in the current format.

Ryan


On 05/17/2010 10:36 AM, Eli Barzilay wrote:
> On May 17, Michael Sperber wrote:
>> Sam Tobin-Hochstadt<samth at ccs.neu.edu>  writes:
>>
>>> On Mon, May 17, 2010 at 8:33 AM, Eli Barzilay<eli at barzilay.org>  wrote:
>>>>
>>>>
>>>>> Possibly, it makes sense to avoid sending e-mails on merge commits,
>>>>> but that's only a bonus.
>>>>
>>>> I don't think so: eg, Sam's recent merge of a long lived branch could
>>>> have (or might have) been pushed as a single merge commit.
>>
>> You mean the individual commits from that branch did not get copied to
>> the main repo?
>
> It depends on the policy of reporting: right now, if those commits
> were already reported on some branch then they might not be reported
> again on the master branch.
>
>
>>> Further, I don't see how it would be useful to try to understand that
>>> merge in terms of 30+ emails, all sent at the same time.
>
> Note that Sam's merge was 86 commits.
>
>
>> I'm assuming that the granularity of your commits communicate
>> something useful about the genesis of what you're doing - that's why
>> we want them in the version history in the first place.  If the 30+
>> commits can only be understood as a whole, they should be pushed as
>> a single commit, not 30+.
>
> I'm sure that those 86 commits are important for *Sam* -- but as far
> as *I'm* concerned it's all a big blurry "stuff happened in typed
> scheme".  I certainly don't want to start thinking about squashing my
> commits just because it's uninteresting for other people -- and
> together with that, I don't want to hear my laptop beep constantly for
> an hour because Sam used a long branch.
>
> Here's a more concrete example that I've used a few times now: when I
> wrote the newly optimized sort, I had about 5 commits in one night
> (should have been done on a git branch, if we had git at the time).
> I can promise you that the intermediate commits are uninteresting to
> anyone (who is not interested in maintaining that code) -- and I had
> them all at the same time before I started committing, so I *could*
> have done the whole thing at one shot (and with svn, there was an
> argument saying that I should have).  But those commits are very
> important to me -- and the though of considering preserving that
> history vs apologizing for 5 emails instead of one seems like a very
> bad idea.
>
> (And to put things in an even more concrete light: say that we had an
> email/commit.  I often mail myself a list of things to buy when I go
> to a supermarket so I can read it there -- what if Sam pushed his 86
> commits while I was on my way?  I'd be standing there in the parking
> lot (no good reception inside), slowly making my way to get to my
> shopping list.)
>