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

[Owen Taylor <otaylor redhat com>]

On Wed, 2009-03-04 at 11:08 -0500, Joe Shaw wrote:
> Hi,
> 
> On Wed, Mar 4, 2009 at 9:54 AM, Owen Taylor <otaylor redhat com> wrote:
> > No cover mail is sent in the simplest case of someone just pushing
> > series of commits at once with no merge or other complications involved.
> > It's possible that the numbering should be left out as well. Though it
> > helps with the current misordering.
> 
> Ah, ok.  Yeah, I'm not sure the numbering buys much, misordering
> notwithstanding.
> 
> >> At least one email (for gnome-bluetooth) had broken metadata:
> >>
> >>     * [no subject], Unknown
> >
> > Looks at that mail in detail - it's an svn commit mail. :-)
> 
> Yeah, but that doesn't explain why the email has a git-style subject?
> Is something being trampled?

Looks like a mhonarc bug actually (or actually more likely a bug in our
script that run mhonarc); what happened was that the commit that start
with 

http://mail.gnome.org/archives/svn-commits-list/2009-March/msg00926.html

Had a line:

"From the properties to common/"

The "From" in the first column caused the mail to be broken into two
pieces in the archive. It's in one piece as delivered to me, which is
why I blame our archiver. (I'm never really sure who is supposed to be
responsible for turning From into >From and back, or when that is
necessary...)

The problem won't occur with git since I add "     " to the start of all
lines in the commit message.

> >> In a large multiple commit batch, many of the emails in the archive
> >> were very out-of-order:
> >
> > 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.

(Weirdly, in thinking about forking off a subprocess, my first question
is how to separate the mails in the stdin to the subprocess - add the
envelope sender "From ... " lines that caused the problem with
mhonarc??? ;-)

- Owen