Here's a compiled list of all branches whose future is yet to be decided:
https://docs.google.com/spreadsheets/d/1Wg0gqbiXdwyb4lt_52UK4C9qnN6yj20vWRlbzlgpJgY/edit?usp=sharing
I didn't have time yet to dig deeper into each one to recommend and action
though.
I've a backup of all the branches befor
Thanks Nuno for the command.
I'm gonna start by deleting the following ones that are safe to remove:
Already merged to (reachable from) master:
git for-each-ref --sort=committerdate
--format="%(committerdate:short),%(objectname:short),%(refname:short),\"%(authorname)\""
refs/remotes/upstream --me
Hello All,
I haven't had experience with automatic branch deletion either, but seems
like a good idea to me. +1.
It looks like a good chunk of the extra branches seem to be from various
large collaborative efforts (e.g. java 11 refactor, ysld). Given that a
bunch of those involved some degree of
Hi Gabriel, Andrea,
no experience with that automation, but I would say +1.
Just cleaned my dangling branch:
>$ git for-each-ref --sort=authorname --format="%(committerdate) %09
%(authorname) %09 %(refname)" refs/remotes/upstream | grep "Nuno Oliveira"
Thu Oct 3 22:57:07 2019 +0200Nuno Oliv
On Sat, Nov 16, 2019 at 7:48 PM Andrea Aime
wrote:
> We should start by making sure once a PR is merged, it's branch gets
>> deleted. Especially the ones created by the backports hook, cause almost
>> all other ones should come from branches on people's forks so each one can
>> do whatever they w
On Fri, Nov 15, 2019 at 12:13 AM Gabriel Roldan
wrote:
> Hey devs,
>
> there are 94 branches in the canonical geoserver repository.
> That doesn't seem right at all.
>
Yes, it's messy for sure.
>
> We should start by making sure once a PR is merged, it's branch gets
> deleted. Especially the o
