updated jgit to 7.x

[romanjanusz]

Direct motivation: support for worktrees

[mzuehlke]

Till now jgit was pinned to 5.x to so the plugin would still support JDK 8

see: https://github.com/sbt/sbt-dynver/blob/main/.scala-steward.conf

[mkurz]

Wouldn't it make sense to bump the required JDK version for sbt plugins to 17 as well, now that Scala 3.8 and sbt 2 requires that as well?
Maybe it's time to do the same with sbt plugins?

[SethTisue]

the plugin is crossbuilt for sbt 1 and sbt 2, and sbt 1 remains in wide use and as a rule, its plugin ecosystem is expected to work on JDK 8. (and sbt 2 is still in release candidates...)

so I think what this PR needs to do is leave the dependency where it is on the sbt 1 side of the crossbuild, and take the upgrade only when building for sbt 2. this will be worth noting in the repo readme, I think

(another possible path forward exists, namely to continue supporting JDK 8 only on a maintenance branch of the plugin, while on main we'd require JDK 17. my sense is that it makes more sense and will be less hassle to do the split along sbt 1 vs sbt 2 lines. but I'm open to debate on this. the context for any debate should include the fact that sbt-dynver is in extremely wide use because it's part of sbt-ci-release)

[SethTisue]

note also that this should be rebased now that #371 has been merged, since that one includes JDK 8 vs 17 stuff

[romanjanusz]

Currently I'm just overriding the jgit dependency, but I wanted to avoid any backwards compatibility issues in case sbt-dynver uses some API that jgit 7.x breaks. Maybe we could have a check in sbt-dynver whether it works with the override?

[SethTisue]

Maybe we could have a check in sbt-dynver whether it works with the override?

Like an extra step in CI or extra CI job? Sure, that'd be fine. You could also document the situation in the repo readme.

But also, I think we really do want to take the upgrade on the sbt 2 side.