Skip to content

Merged branches stay around until they're manually deleted #750

@joshaber

Description

@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)

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions