|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thanks for your comments. Unfortunately, it can't be fixed without a significant risk of breaking compatibility with many of the existing users of the git plugin.
That simplified syntax is used by many jobs in many locations and changing its behavior is likely to have many unintended side effects. That is why Alexander Link's changes to allow refs/heads syntax were used instead of altering the behavior of the existing syntax. The refs/heads syntax allows unambiguous specification of the branch name without altering the meaning of the existing simplified syntax.
That is also why the description of the regex form of branch specification was added to the online help about the same time. The regex form of branch specification had been in the code for quite a while, without online help, when Alexander and I discovered it lurking there. Since it was in the code, we included it in the online help as another way of handling this condition.
There are too many users of the git plugin using it in too many diverse and interesting ways for us to change so fundamental a behavior, even if the behavior seems flawed.
For a good discussion of the challenges associated with the branches to build specification, refer to commit 1, commit 2, commit 3, commit 4, and commit 5