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
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
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
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
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
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
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
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
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.
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.