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<sa...@ccs.neu.edu> writes:
On Mon, May 17, 2010 at 8:33 AM, Eli Barzilay<e...@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.)
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
