[Bug Report] Issue tracker links in commit messages are inconsistent

[bergamin]

If I have two rules that can be applied to the same message, Fork only apply one of them. Example:

But the actual result is this:

The expected behaviour would be both links being applied.

If this is on purpose to avoid conflict, change the behaviour to test for conflict first and if no conflict is found apply both. If conflict is found, skip the rule and try the next

Edit: as mentioned by @Texl, this is dependant on the order in which they appear in the message. The rules are applied as the text is read.

[bergamin]

Update: this link to the tag worked though:

I believe it might have something to do with #, then...

[bergamin]

Has anybody seen this yet? Most of the times I need the PR from the first example

[Texl]

I experimented a bit with this; the issue tracker replacements seem to consume the commit message content buffer from its start to the end of the final pattern match, and are applied one at a time in the order shown in the UI / settings file (.git/issuetracker or .issuetracker).

The only way I'm able to make multiple replacements work is when the issue tracker configuration ordering matches the ordering in the commit message. In my current situation, this is fine - there's two URLs I'd like to generate and they almost always occur in the same order (one is tool-generated and gets appended to the commit message.)

tldr; if the text you're targeting for replacement occurs in a regular order, you can work around this issue by reordering the issue tracker replacement rules to match that order in the configuration file.

e.g. this configuration:

# Integration with Issue Tracker
#
# (note that '\' need to be escaped).

[issuetracker "Jira"]
  regex = "(https://jira.company.com/browse/|)([A-Z]+-\\d+)"
  url = "https://jira.company.com/browse/$2"

[issuetracker "Collab"]
  regex = "(http://collab.company.com/ui#review:id=\\d+)"
  url = "$1"

will successfully highlight both URLs in commit messages like this:

Programmer Notes:
* part of https://jira.company.com/browse/PROJ-1234
Code Review: http://collab.company.com/ui#review:id=12345

[git-p4: depot-paths = "//p4/repo/": change = 123456]

[bergamin]

That's promising! I'll try it out as soon as possible. Too bad I have literally over 100 repos to fix the order...

I'll do it in that different order for the new ones that I receive to manage and wait to fix the rest when/if #1706 gets noticed and becomes a feature...

Edit: just to confirm, changing the order did work

[bergamin]

Here is another example in which the current linking rule doesn't work very well:

The rules in order:

Type	Regexp
Pull Request	(PR \|pull request )(\d+)
Work Item	(#\|feature/\|bugfix/)(\d+)
Tag	(\d+\.\d+\.\d+)

As you can see, it's pretty inconsistent.

I'm not completely sure how this could be fixed, but if you could flag a portion of the text as having already gotten a link being applied to it, or hiding the portions that have already been applied in one rule so the next rule doesn't see it and apply all the rules for all the available text instead of only in order, then I think it could work.

As mentioned before, this issue makes #1706 even more painful...