On the freeorion there are several branches, which are more than 6 month old and are not release branches. Those branches clutter my local autocompletion for no good reason.
This includes:
InvadeThroughShields
Noisiness
PreWarpStart
TechTurnsReductionNotCost
adrianbroher/breathe-docs
adrianbroher/ci-checks
adrianbroher/remove-meters
adrianbroher/remove-utf8cpp
adrianbroher/simple-enum
adrianbroher/slider-model
adrianbroher/untranslate-autodesc
fix-785
Also there is
Government
Government2
which seem to cover essentially the same topic.
I would like to know which one of those can be ditched as the idea was not feasible and which ones of should be rebased and integrated into master.
Also it would be great if the project would enable the automatic deletion of branches on merging a pull request:
adrian_broher wrote: ↑Thu May 07, 2020 6:45 pmThose branches clutter my local autocompletion for no good reason
And I see your name in these branches. Are you talking with yourself?
I worked in the repo with a lot of stale branches. It was not a trouble for me, it just looked ugly. But we had a user prefix (2-3 chars) in the name of each branch and rarely had commits from different persons in one branch.
Everyone can use own fork and have no branches in the main repo.
A limited number of developers can create branches in freeorion repo, and only two of them create development branches. All branches without PRs can be moved to user forks. Other branches can be discussed in PRs.
Also it would be great if the project would enable the automatic deletion of branches on merging a pull request:
+1
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
I'd also propose that dev branches should be kept in the personal forks of the respective dev (which most do anyway), instead of the main repo. That would reduce the clutter substantially. There might be special cases where it's helpful to have a dev branch in the main repo, but I'd expect those to be rare.
As for the existing stale branches: can't say much about them (except the fix-785 one, that one I've deleted today). AFAIK all these are stuff Geoff works on, so he has to comment on that.
As far as these adrianbroher/* branches are concerned, I think these ended up accidentally in the main repo. My guess would be that someone at some point pulled your, Marcel, dev branches (for whatever reason) and then somehow pushed them on the main repo without intending to and probably even being aware of doing so. Assuming you don't need those branches we can probably just delete them.
Vezzra wrote: ↑Fri May 08, 2020 10:54 am
As far as these adrianbroher/* branches are concerned, I think these ended up accidentally in the main repo.
Those are backups made by me from when I left the project. But I already have pulled and rebased those that are still relevant. However I cannot delete them due to lacking permissions.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
adrian_broher wrote: ↑Fri May 08, 2020 11:20 amThose are backups made by me from when I left the project. But I already have pulled and rebased those that are still relevant. However I cannot delete them due to lacking permissions.
Ah, ok, I see. Done. I've just deleted those branches.
Vezzra reportedly deleted the old branches that were from you.
I think I deleted one or two other branches that were unnecessary due to the related pull request being merged.
The two Government branches I use keeping things rebased for all the major refactorings involving moving big chunks of code into different files in the last few months. They'll go away once the Government stuff is merged, hopefully soon after the next release (or perhaps when the release branch is created).
Noisiness is delayed / put off for other stuff, but might come back in the medium term as a way to improve stealth mechanics.
PreWarpStart should be looked at again after the next release and the Government stuff initially goes in.
TechTurnsReductionNotCost can probably be deleted.
InvadeThroughShields might be interesting to make a species trait or otherwise reworked, but probably implemented differently.