Removing old branches in php-src

5 years ago by G. P. B. — view source

unread

Hello internal,

It seems this topic already has been raised a year ago [1] but nothing has
been done.
So I would like to raise the issue again, there are a various of old and
empty branches currently in git, would it be possible to remove them?

Best regards

George P. Banyard

[1] https://externals.io/message/102982

5 years ago by Sara Golemon — view source

unread

It seems this topic already has been raised a year ago [1] but nothing has
been done.
So I would like to raise the issue again, there are a various of old and
empty branches currently in git, would it be possible to remove them?

1/ Which ones specifically? Some release branches are empty only
because they didn't need to be patched after release (and our release
process was different). Some are old and even "abandoned", like the
first-unicode-implementation, but they serve a useful historical purpose.

2/ Why? Git branches are lightweight and don't really impact the project
in any way beyond enumerations. I'm not against getting rid of truly
pointless branches, but I'm also not sure what the appeal is.

-Sara

5 years ago by Joe Watkins — view source

unread

Morning,

I pretty much just echo what Sara said, I'm not sure what harm they are
doing ...

Cheers
Joe

It seems this topic already has been raised a year ago [1] but nothing
has
been done.
So I would like to raise the issue again, there are a various of old and
empty branches currently in git, would it be possible to remove them?

1/ Which ones specifically? Some release branches are empty only
because they didn't need to be patched after release (and our release
process was different). Some are old and even "abandoned", like the
first-unicode-implementation, but they serve a useful historical purpose.

2/ Why? Git branches are lightweight and don't really impact the project
in any way beyond enumerations. I'm not against getting rid of truly
pointless branches, but I'm also not sure what the appeal is.

-Sara

5 years ago by G. P. B. — view source

unread

Hello,

I think the list compiled in the initial email done by Gabriel Caruso [1]
is a good starting point.

Copied here for reference.

15+ years old:

experimental/RETURN_REF
experimetnal/RETURN_REF_PATCH
experimental/pre_new_hash_func
experimental/zts_stdc_scanners
experimental/rand_redesign
migration/EXPERIMENTAL
experimental/namespaces
migration/unlabaled-1.67.2
experimental/ZendEngine2
experimental/apache_hooks
experimental/apache_hooks
migration/unlabaled-1.3.2

10+ years old:

migration/unlabaled-1.29.2
migration/INITIAL
migration/sqlite-start

Not even 5 years old, but no commit:

str_size_and_int64_56_backport
native-tls
zend-signal-zts

Not even 2 years old, but no commit:

microseconds

Just to be clear I'm not asking to remove Version branches not historical
important ones, but mostly just the ones which have no commit, or are
obsolete.

Best regards

George P. Banyard

[1] https://externals.io/message/102982

5 years ago by Joe Watkins — view source

unread

I saw the list and the ages, what I didn't see was a justification for
removing them.

I think a proper analysis hasn't really been performed, for example the
native-tls branch was merged after ng into the 7.0 series, and I didn't
remove it because it serves as a reference point for the old vs the new way
without digging through a bunch of history/logs/whatever ...

These branches are costing us precisely nothing, just because they are old,
or you don't know what they are for doesn't mean they should be removed.
Good justifications include things like the branch causing confusing
amongst intended audience, a branch containing code so broken that it could
be considered malicious ... and I'm sure other reasons, none of which are
being presented ...

Cheers
Joe

Hello,

I think the list compiled in the initial email done by Gabriel Caruso
[1] is a good starting point.

Copied here for reference.

15+ years old:

experimental/RETURN_REF

experimetnal/RETURN_REF_PATCH

experimental/pre_new_hash_func

experimental/zts_stdc_scanners

experimental/rand_redesign

migration/EXPERIMENTAL

experimental/namespaces

migration/unlabaled-1.67.2

experimental/ZendEngine2

experimental/apache_hooks

experimental/apache_hooks

migration/unlabaled-1.3.2

10+ years old:

migration/unlabaled-1.29.2

migration/INITIAL

migration/sqlite-start

Not even 5 years old, but no commit:

str_size_and_int64_56_backport

native-tls

zend-signal-zts

Not even 2 years old, but no commit:

microseconds

Just to be clear I'm not asking to remove Version branches not historical
important ones, but mostly just the ones which have no commit, or are
obsolete.

Best regards

George P. Banyard

[1] https://externals.io/message/102982

5 years ago by Christoph M. Becker — view source

unread

It seems this topic already has been raised a year ago [1] but nothing has
been done.
So I would like to raise the issue again, there are a various of old and
empty branches currently in git, would it be possible to remove them?

1/ Which ones specifically? Some release branches are empty only
because they didn't need to be patched after release (and our release
process was different). Some are old and even "abandoned", like the
first-unicode-implementation, but they serve a useful historical purpose.

In my opinion, keeping old release branches is not really that useful;
it is more useful to keep the release tags.

Thanks,
Christoph

5 years ago by Peter Kokot — view source

unread

Hello internal,

It seems this topic already has been raised a year ago [1] but nothing has
been done.
So I would like to raise the issue again, there are a various of old and
empty branches currently in git, would it be possible to remove them?

Best regards

George P. Banyard

[1] https://externals.io/message/102982

Hello,

Consistency, cleanliness, good organizational things are a virtue. It
is not an OCD thingy as some might present it. It is an essential part
of good organization. Even with a list of branches that someone with
access might even mistakenly pushed to origin decades ago.

--
Peter Kokot

5 years ago by Olumide Samson — view source

unread

Maybe it might necessarily not need be removed, if this might be a better
idea, why shouldn't there be a php-archive or something like that as a git
account or repository where all those historical branches may be kept for
historical access?

I think removing isn't making sense to me as well, but archiving them
should be without not much justification like currently requested.

5 years ago by Joe Watkins — view source

unread

We already have a git repository where we keep historical branches, we
don't need to create another.

I'm really not sure what the problem is here, and we have spent far too
long discussing this non issue.

Cheers
Joe

Maybe it might necessarily not need be removed, if this might be a better
idea, why shouldn't there be a php-archive or something like that as a
git
account or repository where all those historical branches may be kept for
historical access?

I think removing isn't making sense to me as well, but archiving them
should be without not much justification like currently requested.