Revision as of 14:45, 1 January 2021

Ideas for JGit 6.0

Ideas for a possible scope for JGit 6.0. This is not yet a definitive roadmap or feature list for 6.0; so far, it's just a collection of things that could be done for 6.0.

Putting together a binding roadmap for an open-source project maintained by volunteers is nigh impossible since what ultimately gets done depends on the interests of the volunteers, and on the time they have. (Even people employed to work on JGit are volunteers: their employer donates their time and knowledge, and that employer likely will have them work on things of interest to him, just like any other volunteer.)

So this is an attempt to put to together a collection of ideas from which we could then define a reasonable scope for JGit 6.0. This list is by no means complete; feel free to add items or to comment on them.

Java Version

• Bump the BREE to Java 11.
  • Enables use of Jetty 10/11, which requires Java 11
  • Java 11 brings a new HttpClient, which might yield opportunities for TransportHttp. (Though that might need a lot of code changes.)
  • Java 11 might mean that users may need to re-evaluate memory consumption and GC tuning. See bug 569917, comment 8.
  • Requires switching toolchain in CI builds. (If both Java 8 and Java11 builds are to be done: choose toolchain in build file, or need separate builds.)
  • Android users might get stuck on the 5.x series?

Clean-ups

• Remove deprecated methods.
• Remove JSch completely.
• There was a proposal to re-vamp the JGit exception hierarchy. See for instance this thread on jgit-dev.
• Miscellaneous minor clean-ups:
  • CommitCommand.setCredentialsProvider() is not fluent (should return the CommitCommand). A really minor thing, but apparently not possible without breaking API?
  • LogCommand.call() returns a RevWalk as an Iterable. The RevWalk thus cannot be properly closed (unless it's downcasted). See bug 439305 and bug 530757.
• Other API clean-ups/refactorings?

Platform Specifics

JGit works best on Linux or OS X, simply because that is what most users and maintainers use. We're likely to never notice some of the quirks that may exist in corner cases on other platforms.

Some things could perhaps be improved:

• Support for symlinks on Windows. See bug 568955. Not sure what the situation on recent Win 10 with Java 11 is; perhaps one could finally improve this.

Missing Features

Should new features even be included in the scope of 6.0? In principle, new features can also be done in the 5.x series. Anyway, here's a few of the larger things missing in JGit in no particular order:

• git protocol V2: packfile-uris.
• Support for shallow and partial clones.
• Support for remote helpers.
• Support for git-worktree. (Some changes in Gerrit.) Main problems here: large feature, unclear how complete the changes are, lack of review time, test coverage.
• Support for external diffs. (Changes in Gerrit.) Main problems: large feature, lack of review time, test coverage?
• Support for binary patches. See bug 371725 (with two old changes from 2016 in Gerrit, abandoned because of inactivity), and also another Gerrit change pushed three years later and also abandoned because of inactivity.
• Support for diffs (and patches?) of octopus merges. (More than two parents.)
• Better rename detection in RecursiveMerger. See bug 372606. C-git's rename detection is much more elaborate.
• Cherry-picking multiple commits (based on a C-git compatible sequencer). See bug 447115 or bug 495977.
• Support for HTTPS client certificates. See report on stackoverflow.

Many of these features are of interest for client-side use of JGit. This is an area where we are understaffed; there are not many regular contributors in that area. Server-side sees more activity (probably due to the use of JGit in Gerrit, which Google has an interest in).

Feel free to take any of these items (but they're not trivial!) and resolve them before 6.0. :-)