Note that JGit implementation (correctly) does not implement setupSubmoduleUrls and friends. These interfaces were ported over from the original git-plugin implementation for the CLI implementation. I think the correct thing to do is figure out how to avoid needing these, as it seems incredibly weird to attempt this weird "automatic" detection hueristic for the submodule URL.. I think that shouldn't be done at all by the git-client plugin, and probably shouldn't be done in the git-plugin proper either. That sort of magic is really weird, and after digging, I can't figure out what it was originally intended to do.

With 60,000+ installations of the git plugin and the git client plugin, I avoid changing existing behavior in areas which aren't well covered by automated tests, especially in an area as obscure (to me) as submodules.

I made the mistake a few releases ago of making the client requirements more explicit, refusing to allow ancient git command line executables. The Red Hat 5 users had serious problems with the change. I had to revert it within a day or two of that mistake.

Maybe providing more tests would help here? The git-client doesn't use these methods at all, and the git-plugin proper only uses the "updateSubmoduleUrls" and the comments here are completely dubious at best, considering that it is somehow attempting to "locate" where the refs are coming from which is something 100% foreign to git, and seems to be some scheme cooked up by whoever added this functionality in the first place. It certainly doesn't feel like a normal setup or feature. It's highly "magical" in that and it already claims to be only "heuristic" which seems fishy to me.

I do not know what sort of tests would be there, and the methods already mention that they are "deprecated"

It's understandable to not want to break any users, so having more tests for the standard behavior without the weird "hueristic" would be helpful.

Yes, having more submodule tests would be a great help. One of the items listed as needed in the README is "Create submodule tests".

The submodule setupSubmoduleUrls behavior and use case is too obscure to spend the effort implementing it in JGit.

I agree that it's not worth spending any effort whatsoever implementing it in JGit, as I think it's original use was a bit misgiuded.

If it's not worth implementing, can use of it be removed? I've been trying to use submodules with jgit for the last few days in Jenkins and this appears to be the reason it's not working - some part of the recursive submodule fetching calls setupSubmoduleUrls  and so it fails.

I'd say using submodules is a pretty big feature of git to be missing...

If it's not worth implementing, can use of it be removed?

No, I don't generally remove imperfect functionality unless it is shown to be seriously detrimental to other use cases. Either use command line git for submodules or use the withCredentials Pipeline step can provide command line git with the exact arguments to command line git that meet your needs.

I guess my main issue with this was the user experience (although having things just work would be nice...).

Having been using JGit for everything else and it working fine, I innocently enabled the option to recursively fetch submodules and was greeted by a pipeline that failed to even get going with no real explanation as to why, except a cryptic stack trace. It's taken me about 2 days of searching just to find this issue. If this is a thing that is known not to work, it feels as if there should at least be a warning next to the tick box for enabling recursive submodules that it does not work with JGit.

Thanks for the usability improvement suggestion jonnyvb. I like that idea.