Clean up extraneous branches

[eulertour]

There are far too many branches on the repo. The only ones that should be there are master and releases. We need to work on closing the ones that are there and prevent opening new ones.

[kilacoda-old]

So, we should have everyone develop their stuff on personal forks instead of individual branches?

[behackl]

So, we should have everyone develop their stuff on personal forks instead of individual branches?

Yes!

It might make sense to have separate branches on this repo for large changes that don't make sense to include on a PR-by-PR-basis, but in general everyone should use their own fork.

[cobordism]

I agree that you can have branches for larger work / refactoring but should not for regular small day-to-day stuff.

On that note, please delete branch all_tex_fonts_community -thanks

[behackl]

I am deleting all branches attached to closed PRs now.

[MysaaJava]

Yes please delete branches, i'm lost with my fork that is way to messy !

[behackl]

I am deleting all branches attached to closed PRs now.

Correction: I'll delete those where I know that they are safe to delete. That's not clear (to me) for all closed PRs.

[kolibril13]

Hi,
I agree that there are too many branches right now, however, I also have a point why we should still make branches at the repo itself.
Point 1: It is really easy to test new branches from other users locally.
The procedure when the branch is on the ManimCommunity repo:

1. Fetch new changes from ManimCommunity
2. checkout branch
3. Delete Branch

The procedure when the branch is on a private fork repo:

1. Set a new remote repo from that private fork on the local computer (which is quite annoying).
2. Checkout the right branch
3. Delete Branch
4. Remove the remote repo from that private fork on the local computer.

Please, tell me, if there is a better way of doing this! :)

Point 2: It will be more complicated to make collaborative work.

• On a ManimCommunity branch, all Community devs can simply make a commit and push it.
• On a private repo fork, when user A wants to contribute to a PR of user B, the procedure would be the following:
  • User A has to set a new remote repo from the GitHub of B
  • Check out the right branch
  • Commit and push to a new branch to the fork of user A
  • Then make a PR to the fork of user A

Idea:
So my idea is that in some collaborative cases we still use the ManimCommunity repo for development branches.
To keep the temporary branches organized, we could make all branches start with tmp_ , so they are not too distracting.

[behackl]

Please, tell me, if there is a better way of doing this! :)

Use something like the github cli tool (https://github.com/cli/cli) and say gh pr checkout 576 to checkout the branch belonging to PR 576.

On a private repo fork, when user A wants to contribute to a PR of user B, the procedure would be the following

I don't think that is true: I just pushed commits to #557 simply by pushing to the correct branch on the correct remote. I think that everyone with write access on the org can push to branches from private forks as long as there is an associated PR.

The github client tool really makes life a lot easier here.

I think we should only create new branches on the org repo for large changes which have to be included all-at-once, but where there might still be a series of PRs introducing them. (Something like abolishing CONFIG dirs maybe, but I don't think that couldn't be done step by step.)

[kolibril13]

Ohh, I did not know that something like that existed.
Thanks a lot for sharing!
I just did sudo snap install gh --edge and will try this out right now.

[naveen521kk]

Please, tell me, if there is a better way of doing this! :)

You can use GitHub Desktop.

[MysaaJava]

And i'm partial to remove as much branches as possible, because, i have many branches in my personal fork for which i don't understand the meaning, i don't know why they are here. And, it may be more comfortable for Community developpers, but it is annoying for contributors not from the Community (those without write-access)

[behackl]

I would like to rename the current releases branch to stable -- as far as I have understood, releases is the stable branch we were talking about in our meeting recently.

There are two advantages with naming it stable: (1) The name is a bit clearer and its existance also somehow signals that master might be unstable [there has been confusion on Discord about it]. (2) Our documentation has a version "stable" for which RTD has some magic: it points to the latest released version by default, but if a "stable" branch exists, it points to whatever version it is on.

I'll push stable in a moment, but will not delete the releases branch just yet in case someone has any objections.

(If we had a devops team, I'd CC them here.)

[leotrs]

(If we had a devops team, I'd CC them here.)

#622

[eulertour]

Naming the branch stable is fine, the only reason I didn't do it initially is because it isn't really stable.