Merged branches stay around until they're manually deleted

[joshaber]

@shiftkey writes

In previous versions of Desktop, we had this behaviour for pruning:

• after a sync was completed, this is a chance to find branches that have been merged and removed locally
• if the current branch is in a detached HEAD or unknown state, skip pruning
• we look for branches which have been merged into the default branch (not the current branch)
• on Windows we also had some additional guards to skip reserved branch names, like gh-pages

I've created a branch prune-merged-braches-demo that shows how you might add this into our process, but is deliberately incomplete - the TODO statements need to be addressed as part of implementing this.

There might be some changes with how we do this, but this is a great chance for someone who cares about this feature to have a go at implementing it!

Problem statement:

Branches stick around in Desktop indefinitely until manually deleted. I want the branches that show up in Desktop to be relevant to me and not muddied by stale branches.

Proposed solution:

If

• a branch is deleted on GitHub.com and
• merged locally into the default branch in Desktop and
• has no commits ahead of the default branch

then

• they should be deleted in Desktop after a certain amount of time (to allow for people who frequently reuse the same branch for their work if that's a common workflow).

Considerations:

1. If there's a difference between the commits of the remote on GitHub.com and your local branch, we should not delete the local branch.
2. If GitHub has a concept of reserved branch names as @shiftkey references above (like gh-pages), we should skip pruning those branches.
3. If there's work that's not merged into default on GitHub.com (for example, a PR that's closed and deleted), we should not delete the local branch because it has work that's ahead of the default branch.

Questions:

1. How long before we automatically prune branches? (14 days)
2. How frequently do we check branches for ability to be pruned? (once per day)
3. Do we show anything in the UI to indicate that a branch will be pruned? (We don't think so - we're being intentionally conservative here and we don't think we'll put you in a position to lose any work here)
4. Are there reserved branches here that we should account for? (unknown)
5. Does it make sense to consider squashed and merged branches here (Feature: Prune local squash-merged branches #1771)? (unknown)

[alrz]

Copying my comment from #1128 (comment) at @shiftkey request.

when I choose to update all remotes it'd be nice if it run in parallel -- git remote update --prune does it sequentially.

[caiofbpa]

After I merge PRs on GitHub, their locally checked out branches end up stale in my local repo. So I often run locally the following command:

git branch --merged | grep -v "master" | grep -v "*"| xargs git branch -d

I'm thinking about opening a PR that adds a "Prune merged branches" (needs better wording) to the Repository or Branch menus.

Is this what this issue is about? Or is it about pruning remote branches that were fetched locally?

[iAmWillShepherd]

@caiofbpa this is about pruning local branches. Your original thinking is correct.

[jpike88]

Ugh this issue is over a year old, too bad. I thought more people would be in need of something like this.

[shiftkey]

@jpike88 I've updated the issue with extra details about the feature and what's required, to make clear that this is something an external contributor can pick up and have a go at!

[iAmWillShepherd]

@billygriffin could you clarify which branches we should be pruning. Specifically, should I

1. Prune all branches in all repos that Desktop tracks or
2. Only prune the branches of the currently opened repo?

If we go with option 1, there's a chance the app could be closed mid-way through the cleanup, meaning we need to persist this state to some longer term place than memory. Do you have a preferred way of handling this? Do we resume when app opens or when the scheduled time arrives in situations like this?

If we go with option 2, that may lead to a scenario where the branches are never marked for cleanup because the user briefly opened the repo before moving on, not giving us enough time to kick off our cleanup process.

[billygriffin]

Good question @iAmWillShepherd.

If we go with option 1, there's a chance the app could be closed mid-way through the cleanup, meaning we need to persist this state to some longer term place than memory.

If the app is closed mid-way through the cleanup, then the next time we check, wouldn't it just do the check again and anything that didn't get caught the first time would now get pruned appropriately? I'm not certain why we'd need to persist state. It doesn't really matter if it doesn't get all the way cleaned up if we'll be checking again at some interval, right?

[nerdneha]

I think we want option 1 but with some stipulations, as @iAmWillShepherd and @billygriffin mentioned above: that prune when the app when it starts again if it wasn't completed.

If we do that and we prune at X time each day (for this example 6pm), it sounds like we'd have two actions/checkpoints

1. at 6pm we prune and, upon completion, we store when we’ve pruned**
2. at startup, we check if we pruned at 6pm the day before. if not, we prune now***

** we can store when we have completed pruning or when we start to prune. it’ll affect very few people but it depends on whether we want to re-prune again on startup if they quit at 6:00:05pm vs. just waiting until the next day
*** it can be now or like in 15m so the system can start up without also adding a spike in memory usage to prune (if that's something we're worried about)

I think the biggest risk is performance. We're going to have to see how much of a performance hit we take during pruning, though. If it's too intense, we might have to change to option 2. Maybe there's a quick way to assess that before we finalize the feature?

[j-f1]

This should take into account the last time the branch was checked out/created. I can imagine some use cases where it might be useful to locally create a branch with an old revision where it would be annoying if the branch was deleted.

[GhostLyrics]

Is this restricted only to Github.com hosted repositories or is it actually:

• a branch is deleted on the default remote and
• merged locally into the default branch in Desktop and
• has no commits ahead of the default branch

I'm asking because I use the Desktop client as a general purpose git tool, not just solely for github.com projects.

[billygriffin]

@GhostLyrics Thanks for the question! For now it is restricted to GitHub.com. We chose to make this very conservative since it is destructive and we have a much better understanding of the information we receive from the GitHub API relative to other hosting providers. We likely won’t optimize for other services in the near term but we aren’t opposed to revisiting down the line.

[VelocityIsntSpeed]

Do you check if there are stashed changes (or just changes) for the branch?

[outofambit]

@VelocityIsNotSpeed we don’t currently but we’ve talked about adding that logic. would you be willing to open a new issue for that?

[zzj0402]

git remote prune origin

https://stackoverflow.com/questions/7726949/remove-tracking-branches-no-longer-on-remote

[yekota-copart]

still the issue is not resolved

[hrvojebusic]

This should be at least an option that user can opt-into for non-GitHub hosted repositories.

When working with non-GitHub hosted repositories with a lot of active contributors, pull becomes useless (always fails with an error) as many merged branches exist and pruning is required.

[JosephTLyons]

Any idea on what the progress of this is?

[billygriffin]

@JosephTLyons This is shipped, with the caveat that it's only for repos on GitHub.com. Due to feedback while we were building this, we decided to use 14 days as the constraint prior to pruning local branches so we're not pruning branches people were planning to reuse.

[JosephTLyons]

Thanks for the information, I didn't realize it had shipped.. most likely because I ended up manually deleting branches before 14 days. Thanks for letting me know.

[TaxiTweedy]

@JosephTLyons This is shipped, with the caveat that it's only for repos on GitHub.com. Due to feedback while we were building this, we decided to use 14 days as the constraint prior to pruning local branches so we're not pruning branches people were planning to reuse.

I understand why you would wait 14 days to prune, and i like the option to delete manually in the app once i've merged and deleted the branch on github.com. But....when manually deleting a branch in. the app, the pop up warning states that the branch still exists on remote. Is this a bug?

[billygriffin]

@TaxiTweedy Are you saying you're getting the popup even when the branch no longer exists on the remote? If so, I'm guessing this might be a particularly tricky condition where the app hasn't yet fetched and therefore isn't aware yet that the branch has been deleted.

[TaxiTweedy]

@TaxiTweedy Are you saying you're getting the popup even when the branch no longer exists on the remote? If so, I'm guessing this might be a particularly tricky condition where the app hasn't yet fetched and therefore isn't aware yet that the branch has been deleted.

Yes, exactly. A branch was merged and deleted on remote but appears in the desktop app. This in itself i understand (pruning after 14 days) however the manual option to delete warns that it still exists. I waited several hours after deleting on remote before trying to delete (on app) to see if it was a fetch issue. It feels like the language on the pop up (saying branch exists on remote) was written as static and perhaps doesn't change even if it has been deleted from remote?

[tidy-dev]

@TaxiTweedy I was able to reproduce this behavior. There are two ways to delete a branch: 1) via branch dropdown context menu and 2) via app branch menu. The app branch menu was displaying the correct dialog message, but the branch dropdown context menu was not. I have opened a PR to address this bug. Thank you for the report!

[TaxiTweedy]

There are two ways to delete a branch: 1) via branch dropdown context menu and 2) via app branch menu.

I did not know this (and also just discovered the shortcut)! Thank you for the heads up!

[Gakk]

@billygriffin I am still having the same problem as @TaxiTweedy are reporting. After merging a pull request om GitHub.com i choose to delete the branch from the pull request interface. When returning to GitHub Desktop it shows me an action tip to publish the branch:

I thought that GitHub Desktop should prune branches deleted from GitHub.com after pull request merge?

[grshvetal]

True @Garkk I am having the same issue...

[Slluxx]

Why is this after 6 years still not a thing? People that are just starting out feel like they will break something here. Our GitHub repositorys are set up to delete branches of merged PRs. That leaves us with a bunch of non existing branches that are still visible in Github Desktop. A small button "Sync branches with remote" would help tremendously.

[ekwoka]

Why is this issue closed when it was never addressed and other issues are pointed here as the place to follow it?

[Gakk]

I believe, @Slluxx and @ekwoka, that this feature actually is implemented. Scrolling through earlier comments in this issue I find:

• We've taken an extremely conservative approach [...].
• We chose to make this very conservative since it is destructive.

And from the changelog I find that the feature was implemented in version 2.1.0 released in July 2019:

[New] Branches that have been merged and deleted on GitHub.com will now be pruned after two weeks - #750"

Unfortunately there seems to be even another big limitation for my part, and that is that only branches and pull requests that use normal merges will be pruned. If your workflow uses squash and merge you are out of luck, as this is not detected.

Any improvements to this already implemented issue should probably be registered as a new issue.

[ekwoka]

Thanks. I tried to look through it but I couldn't get much that clarified if and how it worked (it was just clear it wasn't working).

2 weeks can be quite long but manageable, but yes, we do squash and merge everywhere, so it won't work anyway, sadly.

[jackbentley]

we do squash and merge everywhere, so it won't work anyway, sadly.

These tools may be of use to you:

• https://github.com/not-an-aardvark/git-delete-squashed
• https://github.com/jackbentley/git-delete-gh-merged

[ekwoka]

Yes, I've been using gh-poi which does this.