Hello everyone,
I am the author of https://github.com/php/php-src/issues/10007 proposal
and I would ask you for the green light to do so.
There are two kinds of unusefull branches:
a) the PHP-x-y-* branches - I would restrict the removal of branches
that HEAD commit matches git tag HEAD-1 commit
In theory the branches can be used somewhere, but they are pointless as
git tag HEAD-1 is a 1:1 replacement.
No data will/can be lost (and in theory, such branches can be restored
anytime locally).
b) the 10+ years old branches as mentioned in
https://externals.io/message/102982
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 :)
Can we collectively agree?
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
Hello everyone,
I am the author of https://github.com/php/php-src/issues/10007 proposal
and I would ask you for the green light to do so.
There are two kinds of unusefull branches:
a) the PHP-x-y-* branches - I would restrict the removal of branches
that HEAD commit matches git tag HEAD-1 commit
In theory the branches can be used somewhere, but they are pointless as
git tag HEAD-1 is a 1:1 replacement.
No data will/can be lost (and in theory, such branches can be restored
anytime locally).
b) the 10+ years old branches as mentioned in
https://externals.io/message/102982
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 :)
Can we collectively agree?
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,Michael Voříšek
Release managers use these these branches for packaging RCs and
incorporating any critical bug/security fixes between the RC and GA release.
See “Packaging a non-stable release (alpha/beta/RC),” step 3, here:
https://github.com/php/php-src/blob/master/docs/release-process.md#packaging-a-non-stable-release-alphabetarc
To recommend this change, you will need also need to recommend changes
to the release process.
--
Cheers,
Ben
On Tue, Dec 13, 2022 at 11:31 AM Michael Voříšek - ČVUT FJFI <
vorismi3@fjfi.cvut.cz> wrote:
Hello everyone,
I am the author of https://github.com/php/php-src/issues/10007 proposal
and I would ask you for the green light to do so.
Why do you want to remove these branches?
I agree that they have minimal value especially since the tags are the
actual release commit (and for release process versions often represent a
spur off the release branch), but the cost in the repo is negligible. What
is gained from removing information from the repository?
-Sara
Hi
Why do you want to remove these branches?
I agree that they have minimal value especially since the tags are the
actual release commit (and for release process versions often represent a
spur off the release branch), but the cost in the repo is negligible. What
is gained from removing information from the repository?
One benefit of removing those branches would be, that usability of
GitHub's branch selector improves, specifically the branch selector when
creating a new PR.
Currently one needs to know the exact naming scheme and then use the
"Find a branch" input to efficiently find a specific target branch. With
the extra branches removed, one can open the dropdown and simply click
the correct branch without needing to think.
Best regards
Tim Düsterhus
One benefit of removing those branches would be, that usability of
GitHub's branch selector improves, specifically the branch selector when
creating a new PR.
Maybe this is my CLI privilege talking, but who's using pulldowns to select
PR branches? Sepcifically, IME we tend to get PRs against the master
branch.
All that aside, I do agree that the dropdown's contents can be daunting.
It's a big list. But:
1/ We're unlikely to get rid of the release branches 100%. The current RC
cycles have branches for their release so that we can add revisions onto
the RC and get a stable final. So at minimum, there's going to be a
release branch in place for each active release on 16 out of 28 days
(slightly more than 50% of the time). Sure, that's just a couple of
version specific branches instead of hundreds, and that point is well
taken, but my counterpoint is that we will have working branches.
2/ I'm not convinced this is a confusing scheme. While php-src doesn't
follow perfect semver, we certainly have something recognizable to the
broader OSS development community, and if you see PHP-8.0 PHP-8.0.0
PHP-8.0.1 etc... I think a programmer is going to being able to sus out the
meaning of these branches. Even if they don't, the review process will
easily be able to set them straight. TL;DR We can expect a reasonable
amount of sense on the part of anyone who has any reason to be poking
around branches.
Given #2, I don't see a significant benefit, given #1 I see that benefit
being naturally mitigated, and I don't see removing data from our repo as
being valuable.
Just my personal feeling on the matter, don't let me discourage you from
bringing this to an RFC and holding a vote.
-Sara
Hi
[Resending with better compressed attachment, because 30k limit]
first off: I don't care particularly strongly about this matter. I would
be in favor of cleaning out the old branches, but I'm also not in a
position to tell others how to do their job.
One benefit of removing those branches would be, that usability of
GitHub's branch selector improves, specifically the branch selector when
creating a new PR.Maybe this is my CLI privilege talking, but who's using pulldowns to select
I do :-) At $dayjob I also use the 'gh' CLI client, but for
contributions to repositories that are less well-known to me or where I
do a once-off contribution, I prefer the web interface. It makes it
easier for me to double check all the contributing guidelines and to
fill in the PR template properly. Especially when I'm cross-referencing
some other resources I tend to have the browser open and copying links
between browser and terminal is "less than great".
PR branches? Sepcifically, IME we tend to get PRs against the
master
branch.
The majority of PRs likely target master, but there's also a
non-insignificant number of bug fixes that need to go into one of the
earlier branches.
(slightly more than 50% of the time). Sure, that's just a couple of
version specific branches instead of hundreds, and that point is well
taken, but my counterpoint is that we will have working branches.
Exactly, it would just be 'master', 'PHP-8.2', 'PHP-8.1', 'PHP-8.0' and
then 3 additional branches for 'PHP-8.x.y' that actually provide value,
because they are actively used for the next release.
2/ I'm not convinced this is a confusing scheme. While php-src doesn't
I don't believe anyone considers them to be confusing, as you said,
the naming and purpose is clear and well-documented.
However from my experience branches in git are generally considered to
be a thing that actively worked on (and often they are short-lived),
whereas tags are for stuff that is worth preserving, but not something
you interact with actively and this really shows in both git's and
GitHub's UI.
GitHub's branch selector I mentioned before is one thing, but 'git
branch' is also affected. My local php-src copy has 'origin' pointing to
my fork and 'upstream' pointing to php/php-src, allowing me to easily
update from the upstream repository (e.g. git fetch upstream
PHP-8.2:PHP-8.2 PHP-8.1:PHP-8.1 PHP-8.0:PHP-8.0) and to push to my fork.
Now when I want to check my branches, including the branches of my
remotes (i.e. git branch -a), git will also shove all the release
branches in 'upstream' in my face.
The same is true when running 'gitk --all' to easily visualize how my
local branches compare to the state in my fork on GitHub and the state
in php/php-src: It will list all the release branches in addition to the
actual tags, doubling the number of labels shown. I'm specifically
interested in the state of actual long-lived branches of upstream, so
can't just filter out everything in upstream/'. Example screenshot
attached: The branches (green) are pretty distracting there, because my
brain is wired to consider branches to be something of interest based on
other repositories I work with.
Given #2, I don't see a significant benefit, given #1 I see that benefit
being naturally mitigated, and I don't see removing data from our repo as
being valuable.
There's no real data loss, because the release tags are still available
and they are a strict superset of the release branches. Once the release
is out, the branches served their purpose and are never going to be used
again and those branches do not interact nicely with git's interfaces
(see above).
Best regards
Tim Düsterhus