Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119145
Content-Type: multipart/mixed; boundary="------------IX0HibI6i7vEaU39BadaWsiO"
Message-ID: <f63c242d-1d7e-6d8d-92f7-188cbfd5d075@bastelstu.be>
Date: Wed, 14 Dec 2022 22:04:27 +0100
MIME-Version: 1.0
To: Sara Golemon <pollita@php.net>
Cc: =?UTF-8?B?TWljaGFlbCBWb8WZw63FoWVrIC0gxIxWVVQgRkpGSQ==?=
 <vorismi3@fjfi.cvut.cz>, internals@lists.php.net
References: <4c1e58ca94c3069b8704b7068254fe3926c5ad17ab62bf88bfed79de0c62bd10@mahalux.com>
 <CAESVnVoVCkGYtgoYFkA=qNSupo7bDeXEYCyo3VZEKUKWPHYHcw@mail.gmail.com>
 <e8c2c35d-bd57-fa2c-b9d9-aaf3d509115b@bastelstu.be>
 <CAESVnVqfKS5VwV6CDfQoKGqf6sAc8-5gJ1qB5JDndQ+u3w4Mzw@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAESVnVqfKS5VwV6CDfQoKGqf6sAc8-5gJ1qB5JDndQ+u3w4Mzw@mail.gmail.com>
Subject: Re: [PHP-DEV] Remove PHP-x.y.* git branches
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

--------------IX0HibI6i7vEaU39BadaWsiO
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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 <tim@bastelstu.be> 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
--------------IX0HibI6i7vEaU39BadaWsiO--