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

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.


- Owen

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]