git commit mail script

[Brian J. Tarricone]

On Mon, Jun 22, 2009 at 05:37, Jannis Pohlmann<jannis at xfce.org> wrote:

> It also has another downside: It seems mails are sent with a
> granularity of one second. So if you send two mails in the same second,
> mail clients don't know in what order to display them. As a
> consequence, the script requires a 1s timeout between the individual
> mails. Now imagine I merge Thunar's migration-to-gio branch into
> trunk ... the final push would take about two minutes ... well, unless
> we figure out a way to disconnect the commit mail script from the shell
> used for pushing. I tried "nohup <commit mail script> &" but that
> always aborted after the first mail.

Boo, annoying.  Why is this not a problem now with git-svn users,
though?  If I git svn dcommit a bunch of commits at once, won't that
result in an out-of-order flood too?  Maybe git-svn is too slow, and
that "fixes" the problem, though...

> I'd prefer the first solution (one mail per commit), but we need to
> solve the timeout issue. For that we either have to disconnect the
> commit mail script execution from the shell, or we need a cronjob +
> lockfile to send commit mails periodically and let the commit mail hook
> just dump the necessary information somewhere. Or we use a post-receive
> hook but in those it's almost impossible (for me at least) to determine
> which commits belong to a newly-created branch (at the update stage you
> can check which commits don't belong to any ref yet, that's not
> possible at post-receive).

Yeah, just toss the commit mails in a queue somewhere and have a cron
job process it.  I'm not sure why forking off a new background shell
to do it isn't working, though.  Might be easiest to investigate that
and fix it.

     -brian