Forbidding feature branches on JuliaLang/julia repo

Right now the JuliaLang/julia has 914 branches.
I am pretty suire the majority of which are stale feature branches,
where someone started to implement a feature and then for some reason stopped.
Taking a look, in many cases they even stopped without even openning a PR.
(Also in a lot of cases the PR is closed)

Compare to ruby, there are 23 branches, each one just for a release.
Rust normally looks similar though right now they have a few extras, I am not sure what is up with that (maybe some hotfixes).
cpython also.

The reason we have so many more is because people with merge rights tend to create feature branchs on JuliaLang/julia, rather than in their own forks.
Where as people without merge rights do use their own forks.
Where as in all the other language repos i mention, everyone (merge rights or not) create feature branches on their forks.
I think we should be like them.

Its not a huge deal, but it is just kind of annoying when:

  • Looking for release-1.6 in the dropdown branch menu on github
  • managing my own branches and swapping between them locally
  • Pulling changes so i can rebase (since it pulls all the things anyone is working on)

There are ways to work around all of this, like extra git flags (--singlebranch etc)
but i still think it would be better to just save JuliaLang/julia just for master and the release branches,
and do all the feature development on forks.

I propose we do 3 things:

  1. develop some kind of policy like the above
  2. Workout if we can enforce it (e.g. some setting where fewer people can create branchs?)
  3. Delete all stale branchs from the repo
  4. Repeat step 3 every month until all feature branches are gone

+1 for this. It definitely is an avoidable annoyance.


Agreed, it should be cleaned up.


Has there been progress on this / has this been seen and accepted by the core devs? There clearly still are (way too) many feature branches in the Julia repo.

1 Like

Don’t think any Julia devs decided this was a problem. I guess I would be ok with using a fork to make PRs since the gh tool now makes that fairly easy.


Don’t agree :smile:

Perhaps we could make this a thing.
(was reminded about this after I was confused to day by the random release-1.6.0 branch that seems to be a mistake (release-1.6 is the real branch)).
And maybe bring it as a rule into effect as of 1.7 release or as of JuliaCon 2021?


:-1: This has many annoyances for people working regularly on Julia and the arguments for it seems to be extremely easy to workaround.


Type in 1.6 in the search field? You would probably do that any way because there are enough release branches.


Could you explain the use cases and the problems this change would introduce?

1 Like

Speaking for myself (and not related to Julia since I’m not a committer), I regularly open pull requests from forks rather branches in the upstream repository when I do have commit access to upstream. I find that much more useful and safe, especially because I set (well, Magit does that for me) pushurl to use the SSH protocol only for the fork, while I use HTTPS for all the other URLs, so that I can think twice if I get the username/password prompt because I’m pushing to upstream instead of the fork.

Exceptions to my habit include repositories that I moved from my account to organisations and for which I don’t want to break the redirect by creating a fork, but I guess that’s not a concern for most Julia committers.


Please explain what these are.
Like I would think these are just as annoying for people with commit access as for people without.

Though I guess maybe the annoyance is less for experienced contributors as they probably know to use git clone ... --single-branch etc.
In contrast someone who is making there first PR to fix docs or something is going to get 650 branches from origin and another 650 from their fork, in their face (which makes some git GUIs unhappy (also more likely to be used by someone new)

(For interest, julia has over 1150 conttibutors, I think only 1 person in the top 20 doesn’t have commit rights, but after the top 30 most people don’t.
Everyone in the top 100 (all github shows) has made multiple commits per year.)

1 Like