Repository navigation
Support git worktrees #81
Description
I found that running mvn org.hjug.refactorfirst.plugin:refactor-first-maven-plugin:0.5.0-M1:htmlReport from an alternative git worktree resulted in no output.
git checkout prod
mvn org.hjug.refactorfirst.plugin:refactor-first-maven-plugin:0.5.0-M1:htmlReport # works fine here
git branch temp # create a new branch at the same git commit
git worktree add ../other temp # checkout 'temp' branch in other worktree
cd ../other
mvn org.hjug.refactorfirst.plugin:refactor-first-maven-plugin:0.5.0-M1:htmlReport # no output if run here
Activity
jimbethancourt commentedon Oct 17, 2023
Hi @danhaywood,
Thanks so much for the idea and steps to reproduce. 😁 Although this isn't my top priority at the moment, I know worktrees are definitely used. Looking through the jgit javadocs, it looks like jgit does support worktrees.
It may not require much change in the code to support worktrees - the biggest issue will be finding the right calls to make to jgit! Would you be up for creating a PR?
Thanks,
Jim
jimbethancourt commentedon Nov 17, 2024
@danhaywood Looks like this is possible now with the 7.0 stream of JGit, but it would also require that projects use Java 17. Check out https://projects.eclipse.org/projects/technology.jgit/releases/7.0.0
With as many projects that are still using Java 11, I'm hesitant to move to JGit 7 at this time. NewRelic provided statistics earlier this year in https://newrelic.com/sites/default/files/2024-05/new-relic-state-of-the-java-ecosystem-2024-05-29.pdf on the graph on page 5.
However, once I'm able to create a native binary, then I could easily remove the language level requirement and point folks who use older versions of Java in their project to the native executable.