|
||||||||
|
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
Whether we use git rev-parse or some other form, we still have the compatibility problem. The unfortunate definition of that field is that it takes the text from the right of the rightmost slash and uses that as the branch name. I wish it didn't do that, but that is what it does. With over 40 000 installations of the git plugin, I'm confident there are many cases where that behavior is crucial to their use of the plugin. I can't justify breaking their use of the plugin to resolve my concern that the branch specification they used is not doing the right thing.
Users (like you and me) who need more precise (or accurate) specification of the branch name can either use the refs/heads syntax or can use a regular _expression_ to define the branch to build. Both are described in the help. and both are available for use, without breaking compatibility for existing users. Those existing users may just be "lucky" that the current behavior is what they want, but even if they are just "lucky", they will be dissatisfied if the behavior changes.
> Note that this is a regression from the last version of the plugin I used, where "origin/release/flow" did the right thing. I'm not asking for new behavior, I'm asking for previously working branch names to work again.
Which version of the git plugin did the right thing with "origin/release/flow"? I haven't investigated the entire history of the git plugin, but as far as I know, the plugin has behaved this way since at least git plugin 2.0.