Remove PHP-x.y.* git branches

[mvorisek]

Description

Currently there are hundreds of build version (PHP-x.y.*) git branches but they are useless as they reffer to HEAD-1 of related tagged releases.

I propose to:

1. remove all PHP-x.y.* git branches that have tagged releases
2. and update the release process to remove the build version branch once a related release is tagged/pushed (script can check explicitly if previous tag hash matches branch head hash).

[thg2k]

Bold move, it would be nice to clean up the repository.

From a quick check, the following release branches are not contained in their respective tag:

PHP-4.0.5
PHP-4.0.6
PHP-4.0.7
PHP-4.2.0
PHP-4.2.2
PHP-4.3.0
PHP-4.3.1
PHP-4.3.2
PHP-4.3.7
PHP-5.2.1RC1
PHP-5.4.45
PHP-7.1.0
PHP-7.2.0
PHP-8.0.1
PHP-8.0.4

Also the tag l can probably be deleted, it's the same as php-7.0.26 and probably a mistake.

[jhdxr]

it has been discussed years ago.
see
https://externals.io/message/102982
https://externals.io/message/106643

[thg2k]

Those discussions are irrelevant, they don't have any useful content other than "they don't do any harm, why deleting them?", well for once it makes the project look messy and untidy, i.e. badly maintained, plus it makes it hard to find stuff that is truly useful like maintenance branches or feature branches that are somehow active.

Every time I run a git branch -a looking for something, my heads spins and I wonder why the dev team can't get their s*** together.

[cmb69]

If something is controversial, it requires an RFC. Anybody up to pursue that process?

[mvorisek]

There are two kinds of unusefull branches:

a) the PHP-x-y-* branches - I would restrict the removal of branches that HEAD commit matches tag HEAD-1 commit

In theory the branches can be used somewhere, but otherwise they are pointless and I belive this does not require RFC, as we can simply document tag HEAD-1 is a replacement.

No data will/can be lost (and in theory, such branches can be restored anytime, officially or even locally).

b) the 10+ years ones as mentioned in https://externals.io/message/102982 - there is not feedback againts

IMHO they will never be user, they are some leftover of merged or dev branches, in GH, forks are used for new contributions.

I do not expect these branches to be used anywhere. If 20 years old contribution is expected to be finished, the author should have a local git/svn copy and open regular PR for it :)

@cmb69 can we agree or is there really anything controversial?

[Girgias]

The GitHub discussion is not the place to discuss such changes. The internals mailing list is. If no-one complains on there, then you can consider it uncontroversial.

The reason why, is that most people do not read the GH issue tracker.

[sgolemon]

What's the motivation for removing these branches? You've explained why they're low value and I don't disagree, but they're also low cost. What is improved by removing data from our repository?

[bukka]

Closing as this is not the right place for this discussion.