Community
Participate
Working Groups
Created attachment 288026 [details] Screenshot.png When pulling a repository and while waiting trying to delete a branch in another repository the operation blocks, shows a modal "cancel" button, but it's deactivated. => ui freeze until pull completed. stacktrace: java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.win32.OS.WaitMessage(Native Method) at org.eclipse.swt.widgets.Display.sleep(Display.java:4746) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:167) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:368) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:468) at org.eclipse.egit.ui.internal.repository.tree.command.DeleteBranchCommand.execute(DeleteBranchCommand.java:62)
Seemed like an easy thing to fix, but of course nothing is ever simple. TBH, just fixing this non-cancellable dialog _is_ simple. But the blocking comes from the fact that the branch deletion operations runs with the workspace lock. Which brings me back to bug 497511: *why* does branch deletion in the repo view run with the workspace lock at all? Pulling rightly uses a scheduling rule encompassing the projects in the Eclipse workspace from the repository being pulled. After all it is going to modify the workspace. But branch deletion is purely a repository operation. Soo... why does this use a scheduling rule? If it is an attempt to synchronize concurrent operations on the same repository, then it doesn't work: 1. one may have a repository in the Git Repositories view of which no projects are imported in the Eclipse workspace. On such a repo, I can pull and concurrently delete branches. 2. The branch deletion in the history view does not use any scheduling rule, so it would allow deleting branches while a pull was in progress. Either deleting branches never needs to use a scheduling rule, or the history view should also use one. And if the scheduling rule is indeed an attempt to synchronize repository operations, then this whole scheduling rule business would need to b re-thought anyway (globally, throughout EGit) so that it also works for repositories without projects in Eclipse.
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/190742
Actually, the underlying DeleteBranchOperation also uses a scheduling rule, so the *command* definitely doesn't need to use one. But the question remains: why use a workspace scheduling rule at all for branch deletions?
(In reply to Thomas Wolf from comment #3) Thomas, i like that you try to get the to the root of the issue. I would have already appreciated a working cancel button ;-)
(In reply to Jörg Kubitz from comment #4) > (In reply to Thomas Wolf from comment #3) > > Thomas, i like that you try to get the to the root of the issue. > I would have already appreciated a working cancel button ;-) Which https://git.eclipse.org/r/c/egit/egit/+/190742 gives you. (But DeleteBranchOperation still uses a scheduling rule.)
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/190742 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=5ea47b50c91be161078679158bef46852a4ae45d
(In reply to Thomas Wolf from comment #3) > Actually, the underlying DeleteBranchOperation also uses a scheduling rule, > so the *command* definitely doesn't need to use one. But the question > remains: why use a workspace scheduling rule at all for branch deletions? I agree deleting a branch (which is not the current branch) doesn't need a workspace scheduling rule since it does not affect the working tree at all. I any locking is required on jgit level it should be implemented there.
