git commit mail script
Brian J. Tarricone
brian at tarricone.org
Tue Jun 23 22:57:06 CEST 2009
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.
More information about the Xfce4-dev