7 ms·

IMHO, the main advantage of github is that it is an ecosystem. This is a well-thought-out Swiss knife: a pioneering (but no longer new) PR system, convenient is

IMHO, the main advantage of github is that it is an ecosystem. This is a well-thought-out Swiss knife: a pioneering (but no longer new) PR system, convenient issues, as well as a well-formed CI system with many developed actions and free runners. In addition, it is best to use code navigation simply in a web browser. You write code, and almost everything works effortlessly. Having a sponsorship system is also great, you don't have to search for external donation platforms and post weird links in your profile/repository. All in one, that's why developers like it so much. The obsession with AI makes me nervous, but the advantages still outweigh, as for me, the average developer. For now.

curcbit 10mo ago
Github'PR and CI are some of the worst.
baq 10mo ago
> a pioneering (but no longer new) PR system having used gerrit 10 years ago there's nothing about github's PRs that I like more, today. > code navigation simply in a web browser this is nice indeed, true. > You write code, and almost everything works effortlessly. if only. GHA are a hot mess because somehow we've landed in a local minimum of pretend-YAML-but-actually-shell-js-jinja-python and they have a smaller or bigger outage every other week, for years now. > why developers like it so much most everything else is much worse in at least one area and the most important thing it's what everyone uses. no one got fired for using github.
- delusional 10mo ago
  > having used gerrit 10 years ago there's nothing about github's PRs that I like more, today. I love patch stack review systems. I understand why they're not more popular, they can be a bit harder to understand and more work to craft, but it's just a wonderful experience once you get them. Making my reviews work in phabricator made my patchsets in general so much better, and making my patchsets better have improved my communication skills.
- CamouflagedKiwi 10mo ago
  The main thing I like about Github's PRs is that it's a system I'm already familiar with and have a login/account for. It's tedious going to contribute to a project to find I have to sign up for and learn another system. I've used Gerrit years ago, so wasn't totally unfamiliar, but it was still awkward to use when Go were using it for PRs. Notably that project ended up giving up on it because of the friction for users - and they were probably one of the most likely cases to stick to their guns and use something unusual.
  - TheDong 10mo ago
    > Notably [go] ended up giving up on [gerrit] That's not accurate. They more or less only use Gerrit still. They started accepting Github PRs, but not really, see https://go.dev/doc/contribute#sending_a_change_github https://go.dev/doc/contribute#sending_a_change_github > You will need a Gerrit account to respond to your reviewers, including to mark feedback as 'Done' if implemented as suggested The comments are still gerrit, you really shouldn't use Github. The Go reviewers are also more likely than usual to assume you're incompetent if your PR comes from Github, and the review will accordingly be slower and more likely to be rejected, and none of the go core contributors use the weird github PR flow.
    - ncruces 10mo ago
      > The Go reviewers are also more likely than usual to assume you're incompetent if your PR comes from Github I've always done it that way, and never got that feeling.
      - arccy 10mo ago
        there's certainly a higher rejection rate for github PRs
        foldr 10mo ago
        That seems unsurprising given that it’s the easiest way for most people to do it. Almost any kind of obstacle will filter out the bottom X% of low effort sludge.
- PunchyHamster 10mo ago
  I used gerrit a bit at work but any time I want to contribute to OSS project requiring to use it I just send a message with bugfix patch applied and leave, it's so much extra effort for drive by contributions that I don't care. It's fine for code review in a team, not really good in GH-like "a user found a bug, fixed it, and want to send it" contribution scheme
CafeRacer 10mo ago
I'd rather solve advent of code in brainfuck than have to debug their CI workflows ever again.
- sunnyday_002 10mo ago
  Surely you just need the workflow to not have embedded logic but call out to a task manager so you can do the same locally?
  - CafeRacer 10mo ago
    Well then why 99% of GH Actions functionality even exists.
    - esafak 10mo ago
      To lock you in.
      - CafeRacer 10mo ago
        Ergo, I'd rather use brainfuck to program CI.
    - sunnyday_002 10mo ago
      It is fairly common pratice almost engineering best pratice to not put logic in CI. Just have it call out to a task runner, so you can run the same command locally for debugging etc. Think of CI more as a shell as a service, your just paying someone to enter some shell commands for you, you should be able to do exactly the same locally. You can take this a setup furthur and use an environment manager to removing the installing of tools from CI as well for local/remote consistency and more benefits.
officialchicken 10mo ago
Embrace, extend, extinguish. That's not a Victorinox you're looking at, it's a cheap poorly made enshittified clone using a decades old playbook (e-e-e). The focus on "Sponsorship buttons" and feature instead of fixing is just a waste of my time.
matrss 10mo ago
> a pioneering (but no longer new) PR system Having used Forgejo with AGit now, IMO the PR experience on GitHub is not great when trying to contribute to a new project. It's just unnecessarily convoluted.
- esafak 10mo ago
  What do you like most about agit?
  - matrss 10mo ago
    It's just how straightforward it is. With GitHub's fork-then-PR approach I would have to clone, fork, add a remote to my local fork, push to said remote, and open the PR. With agit flow I just have to clone the repository I want to contribute to, make my changes, and push (to a special ref, but still just push to the target repo). I have been making some small contributions to Guix when they were still using email for patches, and that (i.e. send patches directly to upstream) already felt more natural than what GitHub propagates. And agit feels like the git-native interpretation of this email workflow.
DarkNova6 10mo ago
Would you say Github has any significant advantages over Gitlab in this regard? I always found them to be on par, with incremental advantages on either side.
- sunnyday_002 10mo ago
  One of my favourite GitHub features is the ability to do a code search over the whole of GitHub, not sure GitLab has the same when I use to use it?
  - ssivark 10mo ago
    Code search over all of Gitlab (even if available) wouldn't help much when many of the interesting repos might be on Github. To be truly useful, it would need to index repos across many different forges. But there's a tension in presenting that to users if you're afraid that they might exit your ecosystem to go to another forge.
jcmfernandes 10mo ago
> a well-formed CI system Man :| no. I genuinely understand the convenience of using Actions, but it's a horrible product.
- sunnyday_002 10mo ago
  In what way? I've never had an issue other than outages.
- akmittal 10mo ago
  Curious what are some better options. I feel it is completing with Jenkins and CircleCI and its not that bad.
- kakwa_ 10mo ago
  Maybe I have low standards given I've never touched what gitlab or CircleCi have to offer, but compared to my past experiences with Buildbot, Jenkins and Travis, it's miles ahead of these in my opinion. Am I missing a truly better alternative or CI systems simply are all kind of a pita?
  - vbezhenar 10mo ago
    My issue with Github CI is that it doesn't run your code in a container. You just have github-runner-1 user and you need to manually check out repository, do your build and clean up after you're done with it. Very dirty and unpredictable. That's for self-hosted runner.
    - sunnyday_002 10mo ago
      > My issue with Github CI is that it doesn't run your code in a container. Is this not what you want? https://docs.github.com/en/actions/how-tos/write-workflows/choose-where-workflows-run/run-jobs-in-a-container https://docs.github.com/en/actions/how-tos/write-workflows/c... > You just have github-runner-1 user and you need to manually check out repository, do your build and clean up after you're done with it. Very dirty and unpredictable. That's for self-hosted runner. Yeah checking out everytime is a slight papercut I guess, but I guess it gives you control as sometimes you don't need to checkout anything or want a shallow/full clone. I guess if it checked out for you then their would be other papercuts. I use their runners so never need to do any cleanup and get a fresh slate everytime.
bit1993 10mo ago
I don't agree with this at all. I think the reason Github is so prominent is the social network aspects it has built around Git, which created strong network effects that most developers are unwilling to part with. Maintainers don't want to loose their stars and the users don't want to loose the collective "audit" by the github users. Things like number of stars on a repository, number of forks, number of issues answered, number of followers for an account. All these things are powerful indicators of quality, and like it or not are now part of modern software engineering. Developers are more likely to use a repo that has more stars than its alternatives. I know that the code should speak for itself and one should audit their dependencies and not depend on Github stars, but in practice this is not what happens, we rely on the community.
- CuriouslyC 10mo ago
  You don't need to develop on Github to get this, just mirror your repo.
  - deleted 10mo ago
    [deleted]
  - em-bee 10mo ago
    that's not enough, i still have to engage with contributors on github. on issues and pull requests at a minimum.
- mkornaukhov 10mo ago
  I would say that your comment is an addition to mine, and I think so too. This is another reason for the popularity of github. As for me, this does not negate the convenient things that I originally wrote about.
- MangoToupe 10mo ago
  > Maintainers don't want to loose their stars ??? Seriously? > All these things are powerful indicators of quality Not in my experience....
flohofwoe 10mo ago
> In addition, it is best to use code navigation simply in a web browser. IMHO the vanilla Github UI sucks for code browsing since it's incredibly slow, and the search is also useless (the integrated web-vscode works much better - e.g. press '.' inside a Github project). > as well as a well-formed CI system with many developed actions and free runners The only good thing about the Github CI system are the free runners (including free Mac runners), for everything else it's objectively worse than the alternatives (like Gitlab CI).
kunley 10mo ago
The big issue with Github is that they never denied feeding ai with private repositories. (Gitlab for example did that when asked). This fact alone makes many users bitter, even for organizations not using private repos per se.
testdelacc1 10mo ago
Underrated feature is the code search. Everyone starts out thinking they’ll just slap elastic search or similar in front of the code but it’s more nuanced than that. GitHub built a bespoke code search engine and published a detailed blog post about it afterwards.
vthriller 10mo ago
> In addition, it is best to use code navigation simply in a web browser How do you define "code navigation"? It might've got a bit easier with automatic highlighting of selected symbols, but in return source code viewer got way too laggy and, for a couple of years now, it has this weird bug with misplaced cursors if code is scrolled horizontally. I actually find myself using the "raw" button more and more often, or cloning repo even for some quick ad-hoc lookups. Edit: not to mention the blame view that actively fights with browser's built in search functionality.
- jappgar 10mo ago
  Hint: Type the '.' key on any code page or PR.
  - vthriller 10mo ago
    And now it opens... some VSCode-esque editor in the browser that asks me to sign-in? Why would I want something even more resource-hungry and convoluted just to look up a random thing once in a while?
    - jappgar 10mo ago
      If you're familiar with VSCode it's quite handy. If you hate VSCode for some reason then just don't use it.
matheusmoreira 10mo ago
> Having a sponsorship system is also great They have zero fees for individuals too which is amazing. Thanks to it I gained my first sponsor when one of my projects was posted here. Made me wish sponsorships could pay the bills.
zahlman 10mo ago
>a well-formed CI system with many developed actions and free runners. It feels to me like people have become way too reliant on this (in particular, forcing things into CI that could easily be done locally) and too trusting of those runners (ISTR some reports of malware). >In addition, it is best to use code navigation simply in a web browser. I've always found their navigation quite clunky and glitchy.
cmrdporcupine 10mo ago
Well, I guess. It's not a surprise LinkedIn and GitHub are owned by the same entity. Both are degrading down to the same Zuckernet-style engagement hacking, and pseudo-resume self-boosting portfolio-ware. If the value of open source has become "it gets me hired", then ... fine. But that's not why many of us do free software development. GitHub's evolution as a good open source hosting platform stalled many years ago. Its advantages are its social network effects, not as technical infrastructure. But from a technology and UX POV it's got growing issues because of this emphasis, and that's why the Zig people have moved, from what I can see. I moved my projects (https://codeberg.org/timbran/ https://codeberg.org/timbran/) recently and have been so far impressed enough. Beyond ideological alignment (free software, distaste for Microsoft, want to get my stuff off US infrastructure [elbows up], etc.) the two chief advantages are that I could create my own "organization" without shelling over cash, and run my own actions with my own machines. And since moving I haven't noticed any drop in engagement or new people noticing the project since moving. GitHub "stars" are a shite way of measuring project success. Forgejo that's behind Codeberg is similar enough to GitHub that most people will barely notice anyways. I'm personally not a fan of the code review tools in any of them (GitLab, Foregejo, or GitHub) because they don't support proper tracking of review commits like e.g. Gerritt does but oh well. At least Foregejo / Codeberg are open to community contribution.
socalgal2 10mo ago
I don't get what people are complaining about. I haven't run into these AI issues except for Copilot appearing AS AN OPTION in views. Otherwise it seems to be working the same has it always Is there more?
0xedd 10mo ago
[dead]

curcbit 10mo ago

Github'PR and CI are some of the worst.

baq 10mo ago

> a pioneering (but no longer new) PR system having used gerrit 10 years ago there's nothing about github's PRs that I like more, today. > code navigation simply in a web browser this is nice indeed, true. > You write code, and almost everything works effortlessly. if only. GHA are a hot mess because somehow we've landed in a local minimum of pretend-YAML-but-actually-shell-js-jinja-python and they have a smaller or bigger outage every other week, for years now. > why developers like it so much most everything else is much worse in at least one area and the most important thing it's what everyone uses. no one got fired for using github.

delusional 10mo ago
> having used gerrit 10 years ago there's nothing about github's PRs that I like more, today. I love patch stack review systems. I understand why they're not more popular, they can be a bit harder to understand and more work to craft, but it's just a wonderful experience once you get them. Making my reviews work in phabricator made my patchsets in general so much better, and making my patchsets better have improved my communication skills.
CamouflagedKiwi 10mo ago
The main thing I like about Github's PRs is that it's a system I'm already familiar with and have a login/account for. It's tedious going to contribute to a project to find I have to sign up for and learn another system. I've used Gerrit years ago, so wasn't totally unfamiliar, but it was still awkward to use when Go were using it for PRs. Notably that project ended up giving up on it because of the friction for users - and they were probably one of the most likely cases to stick to their guns and use something unusual.
- TheDong 10mo ago
  > Notably [go] ended up giving up on [gerrit] That's not accurate. They more or less only use Gerrit still. They started accepting Github PRs, but not really, see https://go.dev/doc/contribute#sending_a_change_github https://go.dev/doc/contribute#sending_a_change_github > You will need a Gerrit account to respond to your reviewers, including to mark feedback as 'Done' if implemented as suggested The comments are still gerrit, you really shouldn't use Github. The Go reviewers are also more likely than usual to assume you're incompetent if your PR comes from Github, and the review will accordingly be slower and more likely to be rejected, and none of the go core contributors use the weird github PR flow.
  - ncruces 10mo ago
    > The Go reviewers are also more likely than usual to assume you're incompetent if your PR comes from Github I've always done it that way, and never got that feeling.
    - arccy 10mo ago
      there's certainly a higher rejection rate for github PRs
      - foldr 10mo ago
        That seems unsurprising given that it’s the easiest way for most people to do it. Almost any kind of obstacle will filter out the bottom X% of low effort sludge.
PunchyHamster 10mo ago
I used gerrit a bit at work but any time I want to contribute to OSS project requiring to use it I just send a message with bugfix patch applied and leave, it's so much extra effort for drive by contributions that I don't care. It's fine for code review in a team, not really good in GH-like "a user found a bug, fixed it, and want to send it" contribution scheme

CafeRacer 10mo ago

I'd rather solve advent of code in brainfuck than have to debug their CI workflows ever again.

sunnyday_002 10mo ago
Surely you just need the workflow to not have embedded logic but call out to a task manager so you can do the same locally?
- CafeRacer 10mo ago
  Well then why 99% of GH Actions functionality even exists.
  - esafak 10mo ago
    To lock you in.
    - CafeRacer 10mo ago
      Ergo, I'd rather use brainfuck to program CI.
  - sunnyday_002 10mo ago
    It is fairly common pratice almost engineering best pratice to not put logic in CI. Just have it call out to a task runner, so you can run the same command locally for debugging etc. Think of CI more as a shell as a service, your just paying someone to enter some shell commands for you, you should be able to do exactly the same locally. You can take this a setup furthur and use an environment manager to removing the installing of tools from CI as well for local/remote consistency and more benefits.

officialchicken 10mo ago

Embrace, extend, extinguish. That's not a Victorinox you're looking at, it's a cheap poorly made enshittified clone using a decades old playbook (e-e-e). The focus on "Sponsorship buttons" and feature instead of fixing is just a waste of my time.

matrss 10mo ago

> a pioneering (but no longer new) PR system Having used Forgejo with AGit now, IMO the PR experience on GitHub is not great when trying to contribute to a new project. It's just unnecessarily convoluted.

esafak 10mo ago
What do you like most about agit?
- matrss 10mo ago
  It's just how straightforward it is. With GitHub's fork-then-PR approach I would have to clone, fork, add a remote to my local fork, push to said remote, and open the PR. With agit flow I just have to clone the repository I want to contribute to, make my changes, and push (to a special ref, but still just push to the target repo). I have been making some small contributions to Guix when they were still using email for patches, and that (i.e. send patches directly to upstream) already felt more natural than what GitHub propagates. And agit feels like the git-native interpretation of this email workflow.

DarkNova6 10mo ago

Would you say Github has any significant advantages over Gitlab in this regard? I always found them to be on par, with incremental advantages on either side.

sunnyday_002 10mo ago
One of my favourite GitHub features is the ability to do a code search over the whole of GitHub, not sure GitLab has the same when I use to use it?
- ssivark 10mo ago
  Code search over all of Gitlab (even if available) wouldn't help much when many of the interesting repos might be on Github. To be truly useful, it would need to index repos across many different forges. But there's a tension in presenting that to users if you're afraid that they might exit your ecosystem to go to another forge.

jcmfernandes 10mo ago

> a well-formed CI system Man :| no. I genuinely understand the convenience of using Actions, but it's a horrible product.

sunnyday_002 10mo ago
In what way? I've never had an issue other than outages.
akmittal 10mo ago
Curious what are some better options. I feel it is completing with Jenkins and CircleCI and its not that bad.
kakwa_ 10mo ago
Maybe I have low standards given I've never touched what gitlab or CircleCi have to offer, but compared to my past experiences with Buildbot, Jenkins and Travis, it's miles ahead of these in my opinion. Am I missing a truly better alternative or CI systems simply are all kind of a pita?
- vbezhenar 10mo ago
  My issue with Github CI is that it doesn't run your code in a container. You just have github-runner-1 user and you need to manually check out repository, do your build and clean up after you're done with it. Very dirty and unpredictable. That's for self-hosted runner.
  - sunnyday_002 10mo ago
    > My issue with Github CI is that it doesn't run your code in a container. Is this not what you want? https://docs.github.com/en/actions/how-tos/write-workflows/choose-where-workflows-run/run-jobs-in-a-container https://docs.github.com/en/actions/how-tos/write-workflows/c... > You just have github-runner-1 user and you need to manually check out repository, do your build and clean up after you're done with it. Very dirty and unpredictable. That's for self-hosted runner. Yeah checking out everytime is a slight papercut I guess, but I guess it gives you control as sometimes you don't need to checkout anything or want a shallow/full clone. I guess if it checked out for you then their would be other papercuts. I use their runners so never need to do any cleanup and get a fresh slate everytime.

bit1993 10mo ago

I don't agree with this at all. I think the reason Github is so prominent is the social network aspects it has built around Git, which created strong network effects that most developers are unwilling to part with. Maintainers don't want to loose their stars and the users don't want to loose the collective "audit" by the github users. Things like number of stars on a repository, number of forks, number of issues answered, number of followers for an account. All these things are powerful indicators of quality, and like it or not are now part of modern software engineering. Developers are more likely to use a repo that has more stars than its alternatives. I know that the code should speak for itself and one should audit their dependencies and not depend on Github stars, but in practice this is not what happens, we rely on the community.

CuriouslyC 10mo ago
You don't need to develop on Github to get this, just mirror your repo.
- deleted 10mo ago
  [deleted]
- em-bee 10mo ago
  that's not enough, i still have to engage with contributors on github. on issues and pull requests at a minimum.
mkornaukhov 10mo ago
I would say that your comment is an addition to mine, and I think so too. This is another reason for the popularity of github. As for me, this does not negate the convenient things that I originally wrote about.
MangoToupe 10mo ago
> Maintainers don't want to loose their stars ??? Seriously? > All these things are powerful indicators of quality Not in my experience....

flohofwoe 10mo ago

> In addition, it is best to use code navigation simply in a web browser. IMHO the vanilla Github UI sucks for code browsing since it's incredibly slow, and the search is also useless (the integrated web-vscode works much better - e.g. press '.' inside a Github project). > as well as a well-formed CI system with many developed actions and free runners The only good thing about the Github CI system are the free runners (including free Mac runners), for everything else it's objectively worse than the alternatives (like Gitlab CI).

kunley 10mo ago

The big issue with Github is that they never denied feeding ai with private repositories. (Gitlab for example did that when asked). This fact alone makes many users bitter, even for organizations not using private repos per se.

testdelacc1 10mo ago

Underrated feature is the code search. Everyone starts out thinking they’ll just slap elastic search or similar in front of the code but it’s more nuanced than that. GitHub built a bespoke code search engine and published a detailed blog post about it afterwards.

vthriller 10mo ago

> In addition, it is best to use code navigation simply in a web browser How do you define "code navigation"? It might've got a bit easier with automatic highlighting of selected symbols, but in return source code viewer got way too laggy and, for a couple of years now, it has this weird bug with misplaced cursors if code is scrolled horizontally. I actually find myself using the "raw" button more and more often, or cloning repo even for some quick ad-hoc lookups. Edit: not to mention the blame view that actively fights with browser's built in search functionality.

jappgar 10mo ago
Hint: Type the '.' key on any code page or PR.
- vthriller 10mo ago
  And now it opens... some VSCode-esque editor in the browser that asks me to sign-in? Why would I want something even more resource-hungry and convoluted just to look up a random thing once in a while?
  - jappgar 10mo ago
    If you're familiar with VSCode it's quite handy. If you hate VSCode for some reason then just don't use it.

matheusmoreira 10mo ago

> Having a sponsorship system is also great They have zero fees for individuals too which is amazing. Thanks to it I gained my first sponsor when one of my projects was posted here. Made me wish sponsorships could pay the bills.

zahlman 10mo ago

>a well-formed CI system with many developed actions and free runners. It feels to me like people have become way too reliant on this (in particular, forcing things into CI that could easily be done locally) and too trusting of those runners (ISTR some reports of malware). >In addition, it is best to use code navigation simply in a web browser. I've always found their navigation quite clunky and glitchy.

cmrdporcupine 10mo ago

Well, I guess. It's not a surprise LinkedIn and GitHub are owned by the same entity. Both are degrading down to the same Zuckernet-style engagement hacking, and pseudo-resume self-boosting portfolio-ware. If the value of open source has become "it gets me hired", then ... fine. But that's not why many of us do free software development. GitHub's evolution as a good open source hosting platform stalled many years ago. Its advantages are its social network effects, not as technical infrastructure. But from a technology and UX POV it's got growing issues because of this emphasis, and that's why the Zig people have moved, from what I can see. I moved my projects (https://codeberg.org/timbran/ https://codeberg.org/timbran/) recently and have been so far impressed enough. Beyond ideological alignment (free software, distaste for Microsoft, want to get my stuff off US infrastructure [elbows up], etc.) the two chief advantages are that I could create my own "organization" without shelling over cash, and run my own actions with my own machines. And since moving I haven't noticed any drop in engagement or new people noticing the project since moving. GitHub "stars" are a shite way of measuring project success. Forgejo that's behind Codeberg is similar enough to GitHub that most people will barely notice anyways. I'm personally not a fan of the code review tools in any of them (GitLab, Foregejo, or GitHub) because they don't support proper tracking of review commits like e.g. Gerritt does but oh well. At least Foregejo / Codeberg are open to community contribution.

socalgal2 10mo ago

I don't get what people are complaining about. I haven't run into these AI issues except for Copilot appearing AS AN OPTION in views. Otherwise it seems to be working the same has it always Is there more?

0xedd 10mo ago

[dead]