Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup leftover branches #403

Closed
atz opened this issue Jun 7, 2019 · 5 comments

Comments

Projects
None yet
4 participants
@atz
Copy link

commented Jun 7, 2019

The current number of outstanding branches is 246, including many untouched for years. The oldest is now 8575 commits behind. Whatever value was proposed in such outdated changes, the cost and risk of shepherding a few commits through an 8000+ commit rebase (and attendant architectural and organizational shifts) seems greater than the cost of just reimplementing them from scratch, IF they are even still desired.

Obviously, submitters can delete their own topics and maintainers can apply their judgement (i.e. knowledge that a topic was resolved by alternative implementation), but I suggest maintainers also declare basic criteria for purging unmerged topic branches. For example:

  • more than a year old
  • no longer mergeable

TL;DR: Can we delete a few hundred old branches?

@jsiwek

This comment has been minimized.

Copy link
Member

commented Jun 8, 2019

Can you describe what the actual issue or cost that leaving these branches around is causing you ?

I'm not so much opposed to cleaning up, but I'm also not that motivated either since they bother me not at all, so just wondering if I'm missing an important reason why they should bother me :)

I can think of a few minor negatives to deleting branches though:

  • Every deleted branch risks breaking a hyperlink

    • Definitely one link gets broken if the branch was involved in a GitHub PR (though the loss here is not too substantial since the actual changes are still view-able in the PR itself)
    • In rare cases, a GitHub link to the branch may have been sent in email or put on a webpage. A bit more annoying to unintentionally break those.
  • It's possibly easier for people to reference branch names if they don't want to run full master, but pick out just certain changes to try out.

  • For unmerged branches, I'm not too concerned about accidentally losing information since we've got the commit mailing list archives we can dive into to recover diffs of any old stuff we suddenly feel inclined to look at. But I'd still say it's more annoying to have to resort to searching the archive in those rare cases than it would ever be to see a long branch list and have to grep or filter it down (I rarely look at the branch list anyway).

@atz

This comment has been minimized.

Copy link
Author

commented Jun 10, 2019

@jsiwek It's about accounting for work that is relevant. Keeping a branch around suggests that the changes it contains are relevant to the project. If the changes are relevant, they should be rebased, made reviewable and PR'd. If they are not, they should be discarded. If changes are deemed no longer relevant, then hyperlinks and developer references are not a concern.

Zeek has a uniquely long history for an open source project, but personally, I would never go back to a branch from even 3 years ago that is thousands of commits behind. There may be abstract justifications for inaction, but to me, in practice this just looks like deferred maintenance.

One of the responsibilities of any developer is to attempt to maintain compatibility with not just the current featureset, but also pending changes to the code. At present, the question of compatibility across 200+ branches is essentially unanswerable (or at least, exceeds the effort of actual implementation). At worst, the branches represent false starts or already resolved issues that should not be considered the base of future changes.

@rsmmr

This comment has been minimized.

Copy link
Member

commented Jun 10, 2019

Wouldn't be the 1st time I'm going back 3 years (or more) to an old branch honestly ...

@0xxon

This comment has been minimized.

Copy link
Member

commented Jun 18, 2019

Same here - I definitely have gone back to several year old branches - and there are some branches that basically document experiments done (or slight changes performed for papers).

I don't really see any reason to remove unmerged branches - the merged ones we clean out from time to time.

@jsiwek

This comment has been minimized.

Copy link
Member

commented Jun 18, 2019

Don't think it's worth keeping an issue open for this -- there's no example of how the quantity of unmerged branches concretely hinders development (past or future). In fact, sounds like the opposite: removing some old, unmerged branched is more inconvenient for at least 3 core developers.

@jsiwek jsiwek closed this Jun 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.