vscode-gitlens
vscode-gitlens copied to clipboard
Ability to clear out old branches
At work I have waaayyyy too many old branches locally, the majority of which can be deleted. It would be cool if gitlens offered a command to delete all the branches that have been merged into the target branch (ex: main/dev) of the remote.
Command picker -> "Delete old branches that have already been merged into X" -> asks for target branch -> window opens up with list of old branches to be removed, asks if you are sure -> confirm
Stretch goal: Also have the ability to remove branches in the to-delete list in case there is one you want to keep.
While there is no auto-suggest for which branches to delete, you can delete in bulk using the Git Command Palette -> branch -> delete option. There you can multiselect all the branches to delete.
Would have to think more about the UX for integrating some option like that into the existing menu. Although this isn't something that I will likely add myself, but if the community wants to champion it and provide a PR (after discussions) I'm certainly open to it -- of course, depending on the complexity and scope of the changes required.
There’s also an UI problem related to this:
- I create a branch
old-branch, push it (setting its upstream to the remote branch), and using GitHub’s UI, merge it into master and delete it in the remote repo - I
git fetch origin --pruneto get rid of the stale remote-tracking branches.git branch -ashows thatremotes/origin/old-branchis gone - The Branches tree view shows “old-branch ⇄ origin/old-branch” as if the remote-tracking branch still existed
I have two suggestions:
- Make
fetch --pruneandpull --pruneeasily available for people. JetBrains IDEs just do it by default and I never regretted it (as long one uses GitHub and it allows to “restore branch”, nobody will) - The UI should only show “⇄ origin/*” if that remote-tracking branch still exists. I assume you show it because
.git/configstill has info about the upstream, even though it no longer exists
That way people can just see at a glance which branches are not on the remote. And since that’s only branches you didn’t push yet or which you deleted on the remote, it allows a more informed decision about which ones can be deleted.
There’s also an UI problem related to this:
- I create a branch
old-branch, push it (setting its upstream to the remote branch), and using GitHub’s UI, merge it into master and delete it in the remote repo- I
git fetch origin --pruneto get rid of the stale remote-tracking branches.git branch -ashows thatremotes/origin/old-branchis gone- The Branches tree view shows “old-branch ⇄ origin/old-branch” as if the remote-tracking branch still existed
I have two suggestions:
- Make
fetch --pruneandpull --pruneeasily available for people. JetBrains IDEs just do it by default and I never regretted it (as long one uses GitHub and it allows to “restore branch”, nobody will)- The UI should only show “⇄ origin/*” if that remote-tracking branch still exists. I assume you show it because
.git/configstill has info about the upstream, even though it no longer existsThat way people can just see at a glance which branches are not on the remote. And since that’s only branches you didn’t push yet or which you deleted on the remote, it allows a more informed decision about which ones can be deleted.
Thanks, Man!
OK, so both suggestions are implemented now:
git.pruneOnFetchandgit-graph.repository.fetchAndPrunemake this easier- there’s a “⚠” and red font for branches gone from the remote
Now the only thing missing is an easier way to delete those branches.
Maybe there could be an “×” button for branches, and for branches that have the “⚠ missing upstream” state, there will be no confirmation box, they’ll just be force-deleted?
@flying-sheep Did you ever figure out an easy way to delete the branches marked with a “⚠”?
Yes, I have the GitHub Pull Requests extension installed and use the pr.deleteLocalBranchesNRemotes action (CtrlShiftP then start typing “Delete local branches and remote repositories”)
It only works with GitHub that way of course, so this feature request would still be nice to see implemented.