-
Notifications
You must be signed in to change notification settings - Fork 212
feature: delete stale/merged branches #61
Comments
I like it. I was imagining that functionality would belong in a separate app, but as I think more about it, I think it makes sense to be part of stale. Here's a few notes on how I imagine it would work:
|
For the purpose of the current system of defaults in stale, I think that:
should be set to true by default, since it's very easily undone. However, is it worth throwing a check for whether the PR was merged or not? I know I have accidentally closed PRs on my phone before, and there are lots of cases for closing a pr but still using the branch somewhere else.
should be set to either a very high number (90?) or disabled by default. |
Mostly agree with the notes. I would say that automatically pruning branches on re: prune branch that haven't been pushed to in X days. Yeah, disabled by default, and "default" days number should even be 6mo-1yr While we're on the topic, what do folks think of a tool that detects stale repos themselves? I find a lot of open source projects/companies grow the number of repos over time and most of them are completely deprecated after a while. |
My 2c: I think it is hard to detect stale repos. Repos that have no activity may still be consumed as packages by other projects. It is also not going to save cost as Github charges per user and not per repo. |
Is this still relevant? If so, please comment with any updates or addition details. |
I think this is still relevant. |
Does github expose the protected branches set up in the repo? I'd like to be able to use that so my configuration on a repo is not split too much. |
Perhaps, you could apply one of the |
i can certainly see how this functionality would be useful to existing users of the stale bot, but i could also see this being more separate. i am personally not a stale bot user, but i'd love to have some automated help cleaning up old branches |
was considering building this app, but looks like its already been done by @SvanBoxel here 🎉 |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? |
Yes, it is still relevant. |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? |
Any updates on this? because we should not add another bot just for deleting branches, |
This might not be needed now that GitHub has added the ability to auto-delete feature branches after PR merges: https://help.github.com/en/github/administering-a-repository/managing-the-automatic-deletion-of-branches
|
I'd argue this is more important now - with that feature turned on, stale branches tend to be orphaned/abandoned, or long-lived branches now, as opposed to work that's being actively worked on. Whitelist your long-lived branches, enable auto-prune of merged branches, and then let The ideal workflow for this would be to raise a PR with the name "Pruning [branch]", auto-close it, then delete the branch - this would let users browse closed PRs if they need to get back to a branch which has been pruned.
|
what would the interface look like here?
|
Wow! Over 4 years later and still no traction here!
Agree this is still super important today. As @peter-dolkens points out, there are plenty of edge cases where a PR isn't merged or even opened in the first place but still orphaned branches remain. I work at a modestly sized organization with roughly 60 engineers and even with GitHub's native automatic deletion of branches after merge, we still have 500+ stale branches on one of our most used repositories. There are many downstream CI/CD systems that maintain history for these branches until they are deleted upstream.
|
+1 for this as well, should be reopened. |
I think people missing the point branches can be created on the fly and not neccessarily branch that you create PR from is the branch you started off with and soon you end up with lots of stale branches in the repository if you work in a larger team. |
+1 for this. Whilst automatic branch deletion on PR merge is very nice, it doesn't solve the problem of engineers naturally creating many test/experimental branches that just never get merged into mainline. You can't effectively force all engineers in your company to have "Github cleanup" days - automation is the solution. A per-org "maximum unprotected branch age" or similar would be a decent start. |
these can often linger in repos
The text was updated successfully, but these errors were encountered: