Re: [PHP-DEV] Remove PHP-x.y.* git branches
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. On 12/14/22 21:04, Sara Golemon wrote: On Tue, Dec 13, 2022 at 12:03 PM Tim Düsterhus wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Remove PHP-x.y.* git branches
On Tue, Dec 13, 2022 at 12:03 PM Tim Düsterhus wrote: > 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
Re: [PHP-DEV] Remove PHP-x.y.* git branches
Hi On 12/13/22 18:55, Sara Golemon wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Remove PHP-x.y.* git branches
On Tue, Dec 13, 2022 at 11:31 AM Michael Voříšek - ČVUT FJFI < voris...@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
[PHP-DEV] Remove PHP-x.y.* git branches
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
