The solution is opened in a “git worktree”.
This results into the following error message in the log:
[2024-07-09T13:02:19.306] [SonarLint Server RPC request executor] ERROR sonarlint - Cannot access blame info for rider.module
org.eclipse.jgit.errors.NoWorkTreeException: Bare Repository has neither a working tree, nor an index
at org.eclipse.jgit.lib.Repository.getWorkTree(Repository.java:1582)
at org.sonarsource.sonarlint.core.commons.util.gitblame.GitBlameUtils.blameWithFilesGitCommand(GitBlameUtils.java:52)
The message “Bare Repository has neither a working tree, nor an index” is wrong.
However come to think of it, I don’t quite know why SonarLint handles blame data at all. I’m sure there’s a good reason, but I don’t know what you lose if it doesn’t work. I’ll ask about that.
We use JGit library to get file blame information** and as @Colin has mentioned in the references post, JGit doesn’t support the “Git Worktree” feature.
Obviously, we can’t do much on our side to fix the actual issue, but I’ve created a ticket (SLCORE-900) to handle the exception more gracefully.
Thank you for reporting this.
Best,
Vojtech
**The reason we calculate file blame information is to get a date of the latest change which is later used to determine whether a change has been done on a new code or not.
Maybe JGit is the wrong solution for SonarLint if this bug is open for 9 years?
(Recent discussion in the bug looks like a solution in the near future…)
Anyway, you can try to optimize the exception text to be more precise.
And, please check whether this exception influences other activity of SonarLint.
I remember that I looked into the log and found the exception because I was wondering on missing issues in the file.
If git worktree is not working, identifying issues should work anyway.
I’m currently out of office, so I cannot check again.
And, please check whether this exception influences other activity of SonarLint.
I remember that I looked into the log and found the exception because I was wondering on missing issues in the file.
If git worktree is not working, identifying issues should work anyway.
Yes, that is a correct expectation. The issues should be reported even if the JGit exception is thrown. If it’s not the case, please do enable the verbose logs and attach them to this ticket.
Thanks for the reply Lukas. It was tested on our side (Intellij with SonarLint 10.7.0.78874) and issues were reported as expected. That’s why it would be great to get our hands on the verbose logs if you can reproduce the issue on your side. (Once you get the chance, there is no rush).
Some logs (Linux system, same issue with worktree):
Configuring analysis with org.sonarlint.intellij.java.JavaAnalysisConfigurator
Analysing 'LetMeSonarThisTest.java' (ID 3f6f96ed-4cee-41bd-b9b9-ff66a39bc744)...
[2024-08-14T14:31:34.297] [SonarLint Server RPC request executor] ERROR org.eclipse.lsp4j.jsonrpc.RemoteEndpoint - Internal error: org.eclipse.jgit.errors.NoWorkTreeException: Bare Repository has neither a working tree, nor an index
java.util.concurrent.CompletionException: org.eclipse.jgit.errors.NoWorkTreeException: Bare Repository has neither a working tree, nor an index
at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315)
at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320)
at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
at java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:482)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: org.eclipse.jgit.errors.NoWorkTreeException: Bare Repository has neither a working tree, nor an index
at org.eclipse.jgit.lib.Repository.getWorkTree(Repository.java:1582)
at org.sonarsource.sonarlint.core.commons.util.git.GitUtils.createSonarLintGitIgnore(GitUtils.java:133)
at org.sonarsource.sonarlint.core.analysis.AnalysisService.toInputFiles(AnalysisService.java:752)
at org.sonarsource.sonarlint.core.analysis.AnalysisService.getAnalysisConfigForEngine(AnalysisService.java:273)
at org.sonarsource.sonarlint.core.analysis.AnalysisService.analyze(AnalysisService.java:640)
at org.sonarsource.sonarlint.core.rpc.impl.AnalysisRpcServiceDelegate.lambda$analyzeFilesAndTrack$8(AnalysisRpcServiceDelegate.java:136)
at org.sonarsource.sonarlint.core.rpc.impl.AbstractRpcServiceDelegate.lambda$requestAsync$0(AbstractRpcServiceDelegate.java:67)
at org.sonarsource.sonarlint.core.rpc.impl.AbstractRpcServiceDelegate.computeWithLogger(AbstractRpcServiceDelegate.java:135)
at org.sonarsource.sonarlint.core.rpc.impl.AbstractRpcServiceDelegate.lambda$requestAsync$1(AbstractRpcServiceDelegate.java:65)
at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646)
... 4 common frames omitted
Error during analysis ID 3f6f96ed-4cee-41bd-b9b9-ff66a39bc744
org.eclipse.lsp4j.jsonrpc.ResponseErrorException: Internal error.
at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleResponse(RemoteEndpoint.java:220)
at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:204)
at org.sonarsource.sonarlint.core.rpc.protocol.SingleThreadedMessageConsumer.lambda$new$0(SingleThreadedMessageConsumer.java:51)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:840)
Analysis 3f6f96ed-4cee-41bd-b9b9-ff66a39bc744 finished
On 10.8, I was seeing the same stacktrace as Frederic (with or without binding to a SonarCloud project). I have downgraded to 10.6 to get it working again.