Re: Commit emails (was Re: git status update?)

[Behdad Esfahbod <behdad behdad org>]

On 03/16/2009 06:36 PM, Owen Taylor wrote:
> On Wed, 2009-03-04 at 11:30 -0500, Owen Taylor wrote:
> > On Wed, 2009-03-04 at 11:08 -0500, Joe Shaw wrote:
> > > > Yeah, I'm hating that. I don't have much of an idea for fixing though
> > > > other than adding a 'sleep 1' between the mails, making the commit take
> > > > 17 seconds longer and hoping that fixes.
> > > Heh, that was going to be my suggestion as well. :)
> > >
> > > I doubt the timing matters too much on the receiving end -- people
> > > usually don't obsessively reload their mail clients for commit mails,
> > > I assume.  Depending on the volume I might be worried about falling
> > > too far behind, but that's probably not going to be too big of a
> > > problem unless somebody pushes out hundreds of commits at a time.
> > AFAIK, the git push command won't return until the post-receive hook
> > returns, which is more of my concern with adding sleeps (especially if
> > we need a 5 or 10 second sleep rather than a 1 second sleep.)
> >
> > Forking off a process to actually send the mails is definitely possible;
> > we could even run the entire mail script in the background, but I'd
> > generally prefer that bugs that cause it to fall over cause a backtrace
> > on the pusher's terminal rather than silent misbehavior or something
> > being logged some place that will never be read.
>
> Update on this -  I implemented forking off a subprocess and sleeping 5
> seconds between mails a while ago and that seems to mostly (though not
> quite entirely) fix the ordering problem.

Ah that's why when I pushed 16 commits the mails arrived over the next couple 
of minutes.

> Now that I'm more comfortable with the ordering, I've removed the
> numbering except when there is a cover email.

I found the numbering useful.

behdad

> - Owen