Bug 497511 - Delete local branches should be done outside of the main thread
Summary: Delete local branches should be done outside of the main thread
Status: NEW
Alias: None
Product: EGit
Classification: Technology
Component: UI (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
: 547288 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-07-07 13:01 EDT by Lars Vogel CLA
Modified: 2022-02-12 09:16 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lars Vogel CLA 2016-07-07 13:01:28 EDT
If I delete several local branches, the UI freezes. This should be done via a job.
Comment 1 Thomas Wolf CLA 2016-07-10 14:01:45 EDT
That's strange. Branch deletion is done in an IWorkspaceRunnable, holding the workspace lock. Since the currently checked-out branch cannot be deleted anyway, I fail to see how this operation could modify the workspace at all.

Does anyone know why org.eclipse.egit.ui.internal.repository.tree.command.DeleteBranchCommand and org.eclipse.egit.core.op.DeleteBranchOperation use IWorkspaceRunnables? Git blame doesn't give any useful clues.
Comment 2 Lars Vogel CLA 2016-07-10 14:29:33 EDT
The first commit 0213f9296e68c228dedcc75b247708de7c766ebf seems to have introducted that lock. I think it can be removed.
Comment 3 Thomas Wolf CLA 2016-07-10 14:42:41 EDT
(In reply to Lars Vogel from comment #2)
> The first commit 0213f9296e68c228dedcc75b247708de7c766ebf seems to have
> introducted that lock. I think it can be removed.

That's why I wrote git blame gave no useful clues :-) Maybe I should have been clearer...

I'm a bit worried that it was done as a means to avoid that the user does other destructive git operations on the repo while the branch deletion was underway. For instance, deleting the whole repo. Or managing to checkout one of the branches to be deleted, or similar crazy things. That surely would lead to unexpected exceptions.

If that is a concern, doing asynchronous git operations would need to be re-vamped. (Actually, this may also be an issue for background push/pull/fetch... ?)
Comment 4 Lars Vogel CLA 2016-07-10 16:12:44 EDT
(In reply to Thomas Wolf from comment #3)
> That's why I wrote git blame gave no useful clues :-) Maybe I should have
> been clearer...

AFAIK git blame only gives you the changes of the last commit, hence the additional info.
Comment 5 Thomas Wolf CLA 2019-10-12 16:53:55 EDT
*** Bug 547288 has been marked as a duplicate of this bug. ***
Comment 6 Michael Keppler CLA 2019-10-13 14:46:15 EDT
Even if those git operations do not really conflict with workspace changes, they may conflict with each other. Maybe the workspace runnables are just an attempt of queuing those operations to avoid such conflicts? E.g. I have managed several times to delete a big amount of branches and at the same time try to check out one of those branches, see bug 457226.