| No one is paying attention to this as far as I can tell. There is no time frame for implementing a "critical 5 year old new feature request". If someone wants it evaluated, they should submit a pull request, following the contribution guidelines in the git plugin. They should include automated tests which verify the functionality. They should assure that the default behavior of the plugin remains consistent with previous default behavior (so that existing users don't complain when default behavior changes). They should assure that the pull request runs well interactively when the capability is enabled. They should enlist the help of other users to verify that the proposed change is working as expected by those other users. Those users should place their feedback on the pull request. The git plugin is sorely lacking in automated tests to verify its submodule functions. A significant regression in submodule functionality was introduced in git plugin 3.0 due to that lack of automated tests. I'm evaluating the pull request which proposes a fix by writing tests which compare submodule behaviors between git plugin 2.6 with git plugin 3.0. I've spent most of my available development time in the last month creating automated tests of base submodule functionality. The other way to accelerate the evaluation of this type of proposal is to submit a wide array of submodule functionality verification tests for git plugin 2.6, along with a port of those changes to git plugin 3.0 branch. That accelerates evaluation by allowing me to review the proposed change against an existing suite of tests, instead of requiring that I create all those tests and then use them to evaluate the proposed change. |
