Re: Commit emails (was Re: git status update?)
- From: Behdad Esfahbod <behdad behdad org>
- To: Owen Taylor <otaylor redhat com>
- Cc: gnome-infrastructure <gnome-infrastructure gnome org>
- Subject: Re: Commit emails (was Re: git status update?)
- Date: Mon, 16 Mar 2009 18:38:52 -0400
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
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.
] [Thread Prev