when multiple commits are pushed, only the last one can trigger a trac auto-commit message #2231

New Issue

tahoe-lafs · 2014-04-21T22:03:58Z

daira commented

2014-04-21 22:03:58 +00:00

For example: [77767e9e12cbd3e03f8ad917f6d3e8c1e4918c43/trunk] and [4889129f3732219cb9cedb1eb27dec3da3f22db2/trunk] were committed at the same time, one with 'fixes #1847' and the other with 'refs #1847' in the commit message. Only the latter appeared automatically on #1847.

tahoe-lafs added the

labels 2014-04-21 22:03:58 +00:00

tahoe-lafs added this to the undecided milestone 2014-04-21 22:03:58 +00:00

warner commented

2015-04-28 23:00:03 +00:00

I fixed this. It turns out the notification script was always telling trac that the most-recent commit was new. This was wrong in both directions:

if multiple revisions appeared at the same time, such as when you land a merge commit or pushed multiple commits together, trac would only hear about the last one
if an unrelated branch was pushed, trac would hear about the latest commit (on master) again, causing multiple ticket comments, and multiple emails to be sent.

I fixed it to stash the old repo branch (OLD=git rev-parse master) and use that to build a new list (REVS=git rev-list ^OLD master). That list will be empty if nothing has changed.

I fixed this. It turns out the notification script was always telling trac that the most-recent commit was new. This was wrong in both directions: * if multiple revisions appeared at the same time, such as when you land a merge commit or pushed multiple commits together, trac would only hear about the last one * if an unrelated branch was pushed, trac would hear about the latest commit (on master) again, causing multiple ticket comments, and multiple emails to be sent. I fixed it to stash the old repo branch (`OLD=git rev-parse master`) and use that to build a new list (`REVS=git rev-list ^OLD master`). That list will be empty if nothing has changed.