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

[Owen Taylor <otaylor redhat com>]

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. 

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

- Owen