|
||||||||
|
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.
The plugin already has significant challenges the plugin maintaining compatibility among its many different use cases. I'd rather not provide even more opportunities for user surprises by allowing general purpose customization of the parameters passed to git. If we allow you to pass a custom parameter to a specific git command, it seems like that will then guarantee that the plugin must use that exact command and honor that exact parameter indefinitely.
As an example, previously the plugin used "git clone" to populate the repository. When credentials support was added, that was switched to "git fetch". In the future, it may switch back to "git clone". Allowing you to pass arbitrary parameters to a subset of git commands used by the plugin seems like it will either make compatibility even more difficult, or make future changes even more difficult.
Have you considered investigating the area of the plugin where the --tags argument is passed, seeking a way to remove that call to --tags without harming the rest of the plugin?