Redmine

([\s\(,-^])#(\d+)(?=:punct:|\s|<|$)

([\s\(,-]|^)#(\d+)(?=:punct:|\s|<|$)

From Programming Ruby The Pragmatic Programmer's Guide :

A character class matches any single character between the brackets. The characters |, (, ), [, ^, $, *, and ?, which have special meanings elsewhere in patterns, lose their special significance between brackets.

Here is a unit test that goes in changeset_test.rb.

  def test_ref_keywords_any_line_start
    Setting.commit_ref_keywords = '*'

    c = Changeset.new(:repository => Project.find(1).repository,
                      :committed_on => Time.now,
                      :comments => '#1 is the reason of this commit')
    c.scan_comment_for_issue_ids

    assert_equal [1], c.issue_ids.sort
  end

Thanks Pierre, the new regex worked. I did have to delete the repository from the project and re-add it to get it to re-associate the revisions, so perhaps a 're-sync revisions' on the repository settings tab would be good (this would also work then if commit comments get altered which they can with subversion). I'll post a separate ticket about this.

Added #1273 to request a repository history resync method.

Fixed in r1451. Pierre, thanks for your patch.

Hi, this hasn't been merged to the 0.7-stable branch but is marked as fixed for 0.7.2. Will this be merged before the release?

Many thanks

Russell

I've re-opened this because it hasn't been merged to the 0.8 branch (and didn't want it to get forgot if 0.7.2 is released soon). If its not going to be merged, I'll change the target version to 0.8?

Cheers

Russell

Sorry, meant it hadn't been merged to the 0.7-stable branch (in the above comment).

Merged in 0.7-stable in r1474.

This still doesn't work fully. We've got a few cases where we're entering commit comments such as

#6,#7 small change to fix to issues

Using changeset.rb from 0.7.1, and also with the fix applied, will still only associate #7 with the commit. It appears to be to do with the ',' after the bug number causing an issue. We've got other commit comments like this:

Fixed #8, removed a bug in the locking code

And this won't be associated with an issue, but if I edit the log message, remove the ',' so the message reads Fixed #8 removed a bug in the locking code, then delete and re-add the repository so the history is re-fetched, then the association with issue 8 works correctly.

FWIW, whatever passes the revision history to display the hyperlinks for the bugs on the repository browser picks all these tickets out correctly. Should they not just use the same regex?

It would be good to get this fixed before 0.7.2 as we have to keep deleting and re-adding our repositories to our projects to re-sync the history as theirs no 're-sync' option.

Thanks

Russell

We have also noticed the issue where having a comma after a defect # will prevent redmine from being able to associate the commit with the issue.

Lane, I can't reproduce your bug. I commited a message like "foo #1, bar" and the issue 1 was associated with the commit.

Hi Lane, Piere, do you both have referencing keywords set to *? We also have 'fixes' keywords set to '' and every commit we've got on like this, the issue preceding the ',' isn't associated.

Pierre, have you tried a commit such as #1,#2 foo bar to see if both 1 and 2 are associated?

Cheers

Russell

• Referencing keywords : *
• Fixing keywords : fixes

Both commits with "#1,#2 foo bar" and "foo #1, bar" messages associate right.

Hi Pierre, can you try with 0.7.1 then? I've applied the above regex fix to our installation and that fixed the issue where the bug number was at the start of the commit, but not the ',' case. Perhaps something else has been changed on the stable branch that has affected this also?

I'll try and get hold of the stable branch at some point and give it a go too.

Cheers

Russell

OK, I've just done a checkout of 0.7-stable and a commit of

#1,#2,#3 Created trunk, branches and tags

associated the revision correctly.

On our production installation, I've edited changeset.rb as you described above, and this did fix the start of line issue, but commas after issue numbers don't work so I wonder if something else went in to 0.7-stable post 0.7.1 that touched this issue.

Anyway, seems to be working on 0.7-stable so looks like this report can be closed again.

Cheers

Russell