There could be a bug in the version detection logic, but you should probably first check that the version of git being used by your job is the same as the version reported in the pipeline script sh step.
I've not seen any other bug reports of broken version detection. There are specific automated tests in the plugin to confirm that git version numbers in various formats are detected correctly. Those tests don't use 2.11.0 specifically, but they use 2.10.0 and other interesting values near it.
If there is a bug in the detection logic, I'll need to update my acceptance test to exercise that bug.
There seem to be some interesting cases in that acceptance test when running on command line git version 2.11.0, but the cases that I'm seeing are not related to version checking logic. In my case, the git submodule update fails with a warning that there are no common commits. The same message does not appear on at least some other command line git versions. I'll need to extend the acceptance test to execute with each of the versions of command line git in my test environment. That will then tell me if there are problems related to command line git version. Note that the issue I'm investigating shows that in my environment I'm able to perform the expected command line git operations. Thus, at least in my environment, the version check is working, since my investigation could not have started without passing that version check.