Manim: 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]

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.

[leotrs]

I will ask the owners of the following branches to either (a) let us know if you want to keep this branch in the repo, or (b) if we can delete them.

GeometryAdditions @XorUnison
svg_parser @yoshiask
attrs @PgBiel
multiprocess-PoC-(DON'T-MERGE) @XorUnison

[leotrs]

I believe the owners of the above branches have spoken for them in one way or another.

Also, the repo is set up so that it automatically deletes branches once they are merged. We just have to keep reminding everyone to PR from their fork and not from here.

I think we can close this issue now.

[MysaaJava]

Well … i still see branches being created ^^
So, in the end, which branches will remain ? master/stable/release ?

[leotrs]

I'm personally fine with leaving master/stable/release plus any currently active branches.

One of the nice things about opening branches on this repo is that anyone can commit changes directly from GH. This speeds things up a ton, especially for example in docs-heavy PRs. So I'm personally fine with allowing some branches to come directly from this repo, as long as they are few and far between.

[MysaaJava]

The problem with that, is that when someone forks the repo, he gets a bunch of branches which make no sense for him. Unless their is a way to limit some branches from being forked, i would rather you to use, maybe a manim-dev repo, forked from the manim one (maybe private) when PR will still be public.
Also, doing as you said might deter you from creating new branches, to avoid too many branches in the repo, and a separate repo will allow you to create as many branches as you want
PS: by "you", i mean Manim Community Devs

[leotrs]

@MysaaJava, I appear to be wrong, as @behackl let me know a few days ago.

There are two branches open (one by @naveen521kk and one by @XorUnison) with associated open PRs. Once those PRs are merged, those branches should be deleted automatically.

@PgBiel can you please delete the attrs branch?
@kilacoda I'm not sure if you are working on the addon-system branch? If not, please delete it :slightly_smiling_face:

Once @PgBiel and @kilacoda answer, we can close this issue.

[naveen521kk]

I am worried when I use Github Editor it creates a branch here and not my fork.

[leotrs]

Oh yeah I think that's it. TBH I don't mind it that much. We've already
reduced the number of branches by a lot. If you open a branch here, just
make sure to delete it asap and not leave it abandoned. (I also assume that
you use GH editor for quick stuff that is easy to merge so even better).

On Sun, Nov 22, 2020, 10:30 PM Naveen M K [e-mail] wrote:

I am worried when I use Github Editor it creates a branch here and not my
fork.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ManimCommunity/manim/issues/590#issuecomment-731908408,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAILYAHPCJKBIASK6LCNB4DSRHJL5ANCNFSM4S25VOXA
.