Community
Participate
Working Groups
We fixed #576049 to not leave the repo in a confusing state when the blame operation used a null head (e.g. when renaming a branch that shows blame information in the current editor). That's working fine. However, the blame command still fails at a later point for the same case: java.lang.NullPointerException: Cannot invoke "org.eclipse.jgit.lib.AnyObjectId.toObjectId()" because "commit" is null at org.eclipse.jgit.api.BlameCommand.setStartCommit(BlameCommand.java:99) at org.eclipse.egit.ui.internal.blame.BlameOperation.computeRevisions(BlameOperation.java:315) at org.eclipse.egit.ui.internal.blame.BlameOperation$3.run(BlameOperation.java:540) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) A simple fix would be to not call the BlameOperation if head is null. I was just wondering if we should instead try to remove the blame information from the editor in that case since it might be wrong. I.e. call the action that is currently just an anonymous class in BlameOperation line 507.
I never understood why that Object.equals(...) change should have fixed bug 576049. I would fix this as explained in [1]. [1] https://git.eclipse.org/r/c/egit/egit/+/185535/comments/6d84920e_531141be
Given that this null case can occur in the middle of a rename operation, I would not remove the blame info. I suspect that once the rename is through, we get another refs changed event that gives us a consistent state again.
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/192391
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/192391 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=cbfe35223c1a9312c120089050078f5d55583380
