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 <t...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
