Then people need to make it easier to not use GitHub. I get the idea behind doing everything with email, email is vendor neutral. However the user experience is horrible. If they made it a lot easier to use, I would be all over that.
But, it’s hard to use. Especially with how email is restricted these days for reducing spam. I don’t think there’s a good option here. I end up using GitHub for things because it’s less effort out of my limited effort pool.
Edit: to be more succinct, if using email for git contributions is actually easier, then why is it more effort than using GitHub?
GitHub vs email-based workflow sounds like a false dichotomy to me - the platforms mentioned (codeberg, gitlab, …) also have workflows that don’t require e-mail.
Mailing lists are a small component of the overall problem that a central platform like github attempts to solve in a single service. The organization is externalized with mailing lists, and aspects like public discoverability are just not accomplished with mailing lists alone. Examples of efficient organization around mailing lists can be seen in the wild, however most likely not as visually popular as that one github issue you see pop up in a google search.
Then how do I contribute to them on my iPad? How do I send in patches? How do I apply patches? Why is the workflow better than the GitHub one when it is so inconvenient and requires coordination with your mail client when the requisite settings may not exist?
It’s really an accessibility nightmare outside of centralized platforms… I agree 100% on the basis that GitHub is more convenient. However I was just outlining how mailing lists themselves are a portion of the tooling required to accomplish what GitHub provides in their centralized platform for git :)
I don’t care about your Apple device. That aside, the original intended workflow (outside of kernel development, for git in general) was for contributors to publish their own git repositories via HTTP, and for maintainers to pull patchsets from contributors by pulling branches from those repositories directly. Even in communities that have mailing lists set up, contributors often prefer to publish feature branches this way and not use email-based patch management. This method is forge-agnostic.
I appreciate your use of the word “shitty” and the -1 unkind flag. I can use more words, if you like.
The mention of iPads is intentionally disingenuous. Even when jailbroken, iPads are not general-purpose development platforms, and although there is an iPad Linux project, I don’t feel that I could endorse it right now as a way to make iPads into development platforms. This is not a new problem; I used to have an iPod, I ran iPod Linux on it, and I would not consider it a usable platform for anything besides playing music. Apple does make general-purpose computers, but the iPad is not among them. If the question is about how to contribute to Free Software from an iPad, then my reply is that success will be found by finding a different device for development.
Let’s recap the points made so far in this thread:
Email is not as convenient as GitHub for contributing to git repositories
Email vs GitHub is a false dichotomy
iPads can’t be used to contribute via email
Contributions to a git repository can be published as another git repository
My words are shitty
I don’t want to question your reading comprehension, but I really do think that you’re just farming for upvotes. For what it’s worth, I’ve given you as many upvotes as I can. Good luck.
That’s twice in one thread you’ve accused people you disagree with of participating in bad faith. Are your positions so well reasoned and correct that people cannot possibly disagree with you sincerely?
First of all, let’s remember that Github is a fully proprietary service. Using it to host the development of a free software makes no sense if you value freedom.
I’ve heard this argument too many times, and I grow increasingly tired of attempting to reason through it. How is this true… at all? GitHub lets me host practically unlimited code for free. If I value my software being free, this should be the only thing I am concerned with. GitHub is run by capitalists, shocker they’re doing a capitalism or two. There is literally no better way to spread your code to the world than uploading it to GitHub, partially because that’s where all the users are.
The bar for entry for GitHub is extremely low. I learned how to use GitHub’s desktop app almost a decade ago, far before I became comfortable with the git CLI. I’ve met too many people that are not technically adept yet still have a GitHub account and are capable of contributing to projects. I can’t say the same about GitLab, Codeberg, or SourceHut, even if I enjoy parts of those products more than GitHub.
By keeping your project on Github, you are encouraging new developers to sign up there, to create their own project there. Most importantly, you support the idea that all geeks/developers are somehow on Github, that it is a badge of pride to be there.
There’s over 100 million users. The evidence that all the geeks/developers are on GitHub has been weighed, and it is overwhelmingly in GitHub’s favor.
Good code is written when people are focused, thinking hard about a problem while having the time to grasp the big picture. Modern Github seems to be purposely built as a tool to avoid people thinking about what they do and discourage them from writing anything but a new JavaScript framework.
I think this beautifully illustrates the author’s perspective of those millions of users on GitHub: they’re writing bad code that doesn’t need to exist. Modern GitHub has almost exclusively devoted itself to streamlining the contribution process and encouraging communities to form around software projects. There are plenty of features I’m not a fan of, and some obvious changes I would make, but overall GitHub is incredibly easy to teach and use. I would love to say the same about any free alternative, but I can’t.
I avoided GitHub for a long time, for many of the arguments in the article. I eventually got an account about 10 years ago because I learned an important lesson: pick your battles. I don’t like the fact that GitHub is a proprietary dependency for a load of F/OSS projects. I don’t like that it distorts the F/OSS ecosystem by making CI free for some platforms and expensive for others. But when I moved projects there, I got more contributors and more useful contributions. It’s trivial for a user to submit a small fix to a project on GitHub without already having a deep engagement with the project. That is not true of anything else, in part because of network effects. I consider that more Free Software existing should be a primary goal of the Free Software movement and I’m willing to compromise and use proprietary tools to make this happen. At the same time, I’d encourage folks who have a problem with this to keep working on alternatives and come up with some way of funding them as a public service.
GitHub takes down code when requested. It is rather difficult to imagine Free Software properly destroying the system of copyrighted code when we are willing to let copyright complainants take down any code which threatens that system. I don’t think that forges ought to solve this problem entirely, but forges should not be complicit in the reaction against Free Software.
[O]verall GitHub is incredibly easy to teach and use. I would love to say the same about any free alternative, but I can’t.
I recommend that you try out GitLab. If nothing else, it will refine your opinion.
Yes, basically every public forge will take down code when (legally) requested. America has the DMCA process for this; I’m not particularly familiar with German law, but Codeberg, a very strong proponent of free software, also calls out in their TOS:
(4) Content that is deemed illegal in Germany (e.g. by violating copyright or privacy laws) will be taken offline and may lead to immediate account suspension.
Fighting the man and destroying copyright is a nice concept, but it’s a concept that needs to be pushed socially and legally, not just by ignoring the whole thing altogether.
Copyleft is only one approach to fighting copyright, and forges are only one approach to sharing code. It’s easy enough to imagine going beyond forges and sharing code in peer-to-peer ecosystems which do not respect takedown requests; I’m relatively confident that folks share exfiltrated corporate code from past “leaks” via Bittorrent, for example.
What are forges to do? Not accept DMCA requests? Free Software will continue to be incapable of taking down the copyright system, because it works within said system. If you want to change that system, political activism is going to do a lot more than GPL ever could.
I’ve tried GitLab, SourceHut, Gitea, and a few others, and while I enjoy different parts of those products, I couldn’t possibly call them “user-friendly” the same way I can GitHub. https://about.gitlab.com/ is solely an advertisement for they “DevSecOps” platform - this is, of course, really cool, but someone without the necessary background will not care about this. Even though a lot of this is just marketing, that marketing is important in painting an image for potential users. “The place for anyone from anywhere to build anything” speaks volumes while “DevSecOps Solution” silences the room.
I recommend that you try out GitLab. If nothing else, it will refine your opinion.
I don’t understand why GitLab gets all the love. Because as a user of their hosted service, it is really Just. The. Same. Git, pull requests, wiki, projects boards, discussions, CI.
If you want to host your own instance then yes of course .. you can’t do that with GitHub. But for the hosted version - I would say it is just as proprietary and locked-in as GitHub is.
That’s not the bar that was set, though. All I’m suggesting is that GitLab is a free alternative to GitHub, and that (because GitLab is designed to clone GitHub’s UX) GitLab is as “incredibly easy to teach and use” as GitHub. I’ve used GitLab instances in the past, and believe this to be a reasonable and met bar. Neighboring comments recommend Gitea, which also seems like a fine free alternative, and it might also meet the bar; I’m not personally experienced enough with Gitea to have an opinion.
I’d heavily disagree with the “better workflow” line. I’ve generally found github very smooth and easy to work with, and I’m even using it for cases (private repos) where the social case is irrelevant. I’d happily migrate at least that set of my repos for a better workflow, but I haven’t seen any of the competitors have that.
It would be a better post if the author actually said what’s better about those workflows. Currently it really is more of a rant than information.
I’m not even sure why they are annoyed about the social notifications. I need to go out of my way (or accidentally use bare github.com) to see them. And… ok, I just don’t use that part.
I moved all my projects off a while back; some to sourcehut and some to codeberg.
For the most active of them, I left a read-only mirror on github which people could use to continue to submit issues and patches. It seems like a good middle ground for getting more contributions without coming across as fully endorsing the site. (However, I wouldn’t do this for any new projects, just one with an existing set of contributors.)
Contrarian here: I have been enjoying Fossil SCM quite a bit. I would say the “social” side is entirely lacking and the Web Admin needs a lot of work, but overall all the defaults make a lot of sense.
There is a Fossil-hub site that will host your repository on chiselapp.com. However again, social isn’t really the focus. Nor should you necessarily trust chiselapp. Hosting yourself or sharing to a different device is rather easy. Once you realize that you probably just need version control simplified without social pressures rather than a social experience.
I moved to Codeberg after MS started ignoring licenses for their ML crap. Been a good change. Way less visual noise and social media bs too, which is great for me and my well-being.
Still got my Github account but I dont put anything new there anymore. Just use it out of necessity.
I take a POSSE (Publish on Own Site, Syndicate Elsewhere) approach to Github. I self-host a Gitea instance, and create mirrors of some things on Github. For me, the main drawback of self-hosting Gitea is that people need an account to submit changes or issues, and I don’t want to leave account creation open. I’m hoping that federation will solve this problem in the near-ish future.
Not putting it on GitHub yourself doesn’t guarantee that no one else will put it on GitHub. A bunch of repos on GitHub are unofficial mirrors of things hosted elsewhere.
My stance is if it’s on the public internet, it’s going to get trawled up and shoved into some corpus. If not Copilot, something else. IMHO, only winning move is to not publish your code, or to just accept it.
Or design programming languages that are fundamentally unusable for machine-learning approaches. Right now, a decent amount of the information required for code completion is ephemeral; it’s in comments, subroutine names, type annotations, module names, package names, and other metadata that is usually removed by compilers. We can instead work directly with ASTs and refuse to collate them into large-language-model-friendly documents, leaving no textual datasets behind.
…I didn’t send a patch I crafted for small projects because I didn’t know how to send it by mail and was not in the mood to deal with the Github workflow at that particular time.
Interesting. I’ve had the same experience, but replace GitHub with Sourcehut.
Also not being in the mood to deal with the GitHub workflow is just a weird argument considering how extrememly simple it is. You work in Git so I assume they already had a branch with this patch. Then all you literally need to do is click the link that GitHub shows you after you push your code and then type a subject and description of your patch in the PR form.
It takes so little effort or learning to make a contribution through GitHub …
Also not being in the mood to deal with the GitHub workflow is just a weird argument considering how extrememly simple it is
You could say the same thing about sourcehut.
If you know how to use git, then you know how to create a patch. If you signed up for github, presumably you must have an email address, so like … you know how to send emails to people, right? All you have to do is put the two together. You don’t need to sign up for a new account with a new company or any nonsense like that.
The requirement to fork is awkward. I clone your repo, make a fix, but I can’t just push that as a PR branch, I need instead to create my own fork and then push it there and raise a PR. If I have push access, creating a new branch gives me a link in the terminal to create the PR, which is really nice, but doesn’t work for forks.
I spoke to some GitHub folks when the company was still quite young and their biggest regret was treating forks and branches as different things, but it was too entrenched by then to change.
Huh, interesting. I wonder if there’s some heuristic about when it happens. I’ve clicked on that link without thinking and started creating PRs in the wrong repo before.
Me too! Though until now so far I’ve only made the mistake of opening a PR to the upstream when I meant to do it within my own fork, accidentally bothering the upstream devs with my tinkering. (At one point the CommonMark folks were no doubt always pleased to hear from me)
I’ve been a Github user for about 13 years and I don’t have any of the problem the author provides. I don’t check the feed, I don’t interact with notifications a lot, I don’t star stuff or do anything social.
For my own projects, I push and pull my code, sometimes add and resolve issues. For the open source projects that are not a one man show, I interact via issues and enjoy notification mails about issues, or turn them off.
I’m not even trying to defend Github here, but I think under certain circumstances the problems are self-made or just don’t apply to all the users. I don’t see a fundamental difference to codeberg, it’s mostly what you make of it. Maybe I’m just not a maintainer/collaborator of a big enough project that I don’t see the problems.
That said, I don’t plan on closing my account there, it’s just too useful to collaborate because the majority of projects is there. But I’ve mostly not migrated off because of laziness and no urgency to do so, I’m very much against the centralization and MS stewardship.
Personally, I use github for nixvim because, like it or not, that’s where most people are, and for a project that actively values contributions, that just means that using GitHub means more people, which means more contributions, which means more features, which means a better project.
And as for the GitHub workflow, well… I find it’s the easiest one for me, as a maintainer. Maybe it’s easier to send patches using send-mail, honestly I’ve never tried it, but I already struggle with keeping up enough as-is when going through GH’s notifications, if I had to have a whole email-based workflow which involved me reading and manually merging patches… I’d get absolutely nothing done. Also, nice features like CI and approval requirements on PRs means that I can be sure that code that I merge won’t cause any issues.
Heh you know what I mean, obviously don’t want outrageous feature creep, but given this is a set of configuration modules for Neovim plugins, the more plugins supported the better, as long as there’s quality (which I’ve found GitHub’s workflow helps me maintain)
Then people need to make it easier to not use GitHub. I get the idea behind doing everything with email, email is vendor neutral. However the user experience is horrible. If they made it a lot easier to use, I would be all over that.
But, it’s hard to use. Especially with how email is restricted these days for reducing spam. I don’t think there’s a good option here. I end up using GitHub for things because it’s less effort out of my limited effort pool.
Edit: to be more succinct, if using email for git contributions is actually easier, then why is it more effort than using GitHub?
GitHub vs email-based workflow sounds like a false dichotomy to me - the platforms mentioned (codeberg, gitlab, …) also have workflows that don’t require e-mail.
Mailing lists are a small component of the overall problem that a central platform like github attempts to solve in a single service. The organization is externalized with mailing lists, and aspects like public discoverability are just not accomplished with mailing lists alone. Examples of efficient organization around mailing lists can be seen in the wild, however most likely not as visually popular as that one github issue you see pop up in a google search.
Then how do I contribute to them on my iPad? How do I send in patches? How do I apply patches? Why is the workflow better than the GitHub one when it is so inconvenient and requires coordination with your mail client when the requisite settings may not exist?
It’s really an accessibility nightmare outside of centralized platforms… I agree 100% on the basis that GitHub is more convenient. However I was just outlining how mailing lists themselves are a portion of the tooling required to accomplish what GitHub provides in their centralized platform for git :)
I don’t care about your Apple device. That aside, the original intended workflow (outside of kernel development, for git in general) was for contributors to publish their own git repositories via HTTP, and for maintainers to pull patchsets from contributors by pulling branches from those repositories directly. Even in communities that have mailing lists set up, contributors often prefer to publish feature branches this way and not use email-based patch management. This method is forge-agnostic.
The only part of your reply that was a direct reply was the shitty dismissive part.
I appreciate your use of the word “shitty” and the
-1 unkindflag. I can use more words, if you like.The mention of iPads is intentionally disingenuous. Even when jailbroken, iPads are not general-purpose development platforms, and although there is an iPad Linux project, I don’t feel that I could endorse it right now as a way to make iPads into development platforms. This is not a new problem; I used to have an iPod, I ran iPod Linux on it, and I would not consider it a usable platform for anything besides playing music. Apple does make general-purpose computers, but the iPad is not among them. If the question is about how to contribute to Free Software from an iPad, then my reply is that success will be found by finding a different device for development.
My guy I did not flag you, I am simply not alone in thinking you were out of line. Your original reply can be broken down into:
You go on to legit ascribe deliberate dishonesty to the person you were originally replying to:
That’s a pretty shitty way to respond to someone.
Let’s recap the points made so far in this thread:
I don’t want to question your reading comprehension, but I really do think that you’re just farming for upvotes. For what it’s worth, I’ve given you as many upvotes as I can. Good luck.
That’s twice in one thread you’ve accused people you disagree with of participating in bad faith. Are your positions so well reasoned and correct that people cannot possibly disagree with you sincerely?
I’ve heard this argument too many times, and I grow increasingly tired of attempting to reason through it. How is this true… at all? GitHub lets me host practically unlimited code for free. If I value my software being free, this should be the only thing I am concerned with. GitHub is run by capitalists, shocker they’re doing a capitalism or two. There is literally no better way to spread your code to the world than uploading it to GitHub, partially because that’s where all the users are.
The bar for entry for GitHub is extremely low. I learned how to use GitHub’s desktop app almost a decade ago, far before I became comfortable with the git CLI. I’ve met too many people that are not technically adept yet still have a GitHub account and are capable of contributing to projects. I can’t say the same about GitLab, Codeberg, or SourceHut, even if I enjoy parts of those products more than GitHub.
There’s over 100 million users. The evidence that all the geeks/developers are on GitHub has been weighed, and it is overwhelmingly in GitHub’s favor.
I think this beautifully illustrates the author’s perspective of those millions of users on GitHub: they’re writing bad code that doesn’t need to exist. Modern GitHub has almost exclusively devoted itself to streamlining the contribution process and encouraging communities to form around software projects. There are plenty of features I’m not a fan of, and some obvious changes I would make, but overall GitHub is incredibly easy to teach and use. I would love to say the same about any free alternative, but I can’t.
I avoided GitHub for a long time, for many of the arguments in the article. I eventually got an account about 10 years ago because I learned an important lesson: pick your battles. I don’t like the fact that GitHub is a proprietary dependency for a load of F/OSS projects. I don’t like that it distorts the F/OSS ecosystem by making CI free for some platforms and expensive for others. But when I moved projects there, I got more contributors and more useful contributions. It’s trivial for a user to submit a small fix to a project on GitHub without already having a deep engagement with the project. That is not true of anything else, in part because of network effects. I consider that more Free Software existing should be a primary goal of the Free Software movement and I’m willing to compromise and use proprietary tools to make this happen. At the same time, I’d encourage folks who have a problem with this to keep working on alternatives and come up with some way of funding them as a public service.
GitHub takes down code when requested. It is rather difficult to imagine Free Software properly destroying the system of copyrighted code when we are willing to let copyright complainants take down any code which threatens that system. I don’t think that forges ought to solve this problem entirely, but forges should not be complicit in the reaction against Free Software.
I recommend that you try out GitLab. If nothing else, it will refine your opinion.
Yes, basically every public forge will take down code when (legally) requested. America has the DMCA process for this; I’m not particularly familiar with German law, but Codeberg, a very strong proponent of free software, also calls out in their TOS:
Fighting the man and destroying copyright is a nice concept, but it’s a concept that needs to be pushed socially and legally, not just by ignoring the whole thing altogether.
Copyleft is only one approach to fighting copyright, and forges are only one approach to sharing code. It’s easy enough to imagine going beyond forges and sharing code in peer-to-peer ecosystems which do not respect takedown requests; I’m relatively confident that folks share exfiltrated corporate code from past “leaks” via Bittorrent, for example.
What are forges to do? Not accept DMCA requests? Free Software will continue to be incapable of taking down the copyright system, because it works within said system. If you want to change that system, political activism is going to do a lot more than GPL ever could.
I’ve tried GitLab, SourceHut, Gitea, and a few others, and while I enjoy different parts of those products, I couldn’t possibly call them “user-friendly” the same way I can GitHub. https://about.gitlab.com/ is solely an advertisement for they “DevSecOps” platform - this is, of course, really cool, but someone without the necessary background will not care about this. Even though a lot of this is just marketing, that marketing is important in painting an image for potential users. “The place for anyone from anywhere to build anything” speaks volumes while “DevSecOps Solution” silences the room.
I don’t understand why GitLab gets all the love. Because as a user of their hosted service, it is really Just. The. Same. Git, pull requests, wiki, projects boards, discussions, CI.
If you want to host your own instance then yes of course .. you can’t do that with GitHub. But for the hosted version - I would say it is just as proprietary and locked-in as GitHub is.
I feel like every time I log into GitLab I find a new bug.
Don’t get me wrong; I’d still pick it over GitHub, but it’s far, far behind Gitea.
That’s not the bar that was set, though. All I’m suggesting is that GitLab is a free alternative to GitHub, and that (because GitLab is designed to clone GitHub’s UX) GitLab is as “incredibly easy to teach and use” as GitHub. I’ve used GitLab instances in the past, and believe this to be a reasonable and met bar. Neighboring comments recommend Gitea, which also seems like a fine free alternative, and it might also meet the bar; I’m not personally experienced enough with Gitea to have an opinion.
Economies of scale are hard to beat.
One login for all the projects on github.
Automatic back-links between issues lists across all repositories.
And I can get my data back: my commits are easy to clone. I get a copy of all my comments by email (not the default, but an available option).
Some stuff needs a graphql query download to expatriate. Have to admit I don’t do that regularly, so I’m trusting them there.
Cheers to folks that take on this battle against centralization. I’m inclined to put my energy elsewhere.
I’d heavily disagree with the “better workflow” line. I’ve generally found github very smooth and easy to work with, and I’m even using it for cases (private repos) where the social case is irrelevant. I’d happily migrate at least that set of my repos for a better workflow, but I haven’t seen any of the competitors have that.
It would be a better post if the author actually said what’s better about those workflows. Currently it really is more of a rant than information.
I’m not even sure why they are annoyed about the social notifications. I need to go out of my way (or accidentally use bare github.com) to see them. And… ok, I just don’t use that part.
I moved all my projects off a while back; some to sourcehut and some to codeberg.
For the most active of them, I left a read-only mirror on github which people could use to continue to submit issues and patches. It seems like a good middle ground for getting more contributions without coming across as fully endorsing the site. (However, I wouldn’t do this for any new projects, just one with an existing set of contributors.)
Contrarian here: I have been enjoying Fossil SCM quite a bit. I would say the “social” side is entirely lacking and the Web Admin needs a lot of work, but overall all the defaults make a lot of sense.
There is a Fossil-hub site that will host your repository on chiselapp.com. However again, social isn’t really the focus. Nor should you necessarily trust chiselapp. Hosting yourself or sharing to a different device is rather easy. Once you realize that you probably just need version control simplified without social pressures rather than a social experience.
I moved to Codeberg after MS started ignoring licenses for their ML crap. Been a good change. Way less visual noise and social media bs too, which is great for me and my well-being.
Still got my Github account but I dont put anything new there anymore. Just use it out of necessity.
I take a POSSE (Publish on Own Site, Syndicate Elsewhere) approach to Github. I self-host a Gitea instance, and create mirrors of some things on Github. For me, the main drawback of self-hosting Gitea is that people need an account to submit changes or issues, and I don’t want to leave account creation open. I’m hoping that federation will solve this problem in the near-ish future.
That’s a good approach, as long as you don’t mind your code being used for Copilot.
Not putting it on GitHub yourself doesn’t guarantee that no one else will put it on GitHub. A bunch of repos on GitHub are unofficial mirrors of things hosted elsewhere.
My stance is if it’s on the public internet, it’s going to get trawled up and shoved into some corpus. If not Copilot, something else. IMHO, only winning move is to not publish your code, or to just accept it.
Or design programming languages that are fundamentally unusable for machine-learning approaches. Right now, a decent amount of the information required for code completion is ephemeral; it’s in comments, subroutine names, type annotations, module names, package names, and other metadata that is usually removed by compilers. We can instead work directly with ASTs and refuse to collate them into large-language-model-friendly documents, leaving no textual datasets behind.
There’s still e.g. differentiating the interpreters directly, but that’s not what Copilot does.
Yeah, I may have to reconsider.
Interesting. I’ve had the same experience, but replace GitHub with Sourcehut.
Also not being in the mood to deal with the GitHub workflow is just a weird argument considering how extrememly simple it is. You work in Git so I assume they already had a branch with this patch. Then all you literally need to do is click the link that GitHub shows you after you push your code and then type a subject and description of your patch in the PR form.
It takes so little effort or learning to make a contribution through GitHub …
You could say the same thing about sourcehut.
If you know how to use git, then you know how to create a patch. If you signed up for github, presumably you must have an email address, so like … you know how to send emails to people, right? All you have to do is put the two together. You don’t need to sign up for a new account with a new company or any nonsense like that.
The requirement to fork is awkward. I clone your repo, make a fix, but I can’t just push that as a PR branch, I need instead to create my own fork and then push it there and raise a PR. If I have push access, creating a new branch gives me a link in the terminal to create the PR, which is really nice, but doesn’t work for forks.
I spoke to some GitHub folks when the company was still quite young and their biggest regret was treating forks and branches as different things, but it was too entrenched by then to change.
It does:
Clicking that link then takes me to the compare view against the parent main branch, rather than my own fork’s.
Huh, interesting. I wonder if there’s some heuristic about when it happens. I’ve clicked on that link without thinking and started creating PRs in the wrong repo before.
Me too! Though until now so far I’ve only made the mistake of opening a PR to the upstream when I meant to do it within my own fork, accidentally bothering the upstream devs with my tinkering. (At one point the CommonMark folks were no doubt always pleased to hear from me)
It’s only simple because you’re familiar with it. I found the “pull request” system extremely confusing at first.
I’ve been a Github user for about 13 years and I don’t have any of the problem the author provides. I don’t check the feed, I don’t interact with notifications a lot, I don’t star stuff or do anything social.
For my own projects, I push and pull my code, sometimes add and resolve issues. For the open source projects that are not a one man show, I interact via issues and enjoy notification mails about issues, or turn them off.
I’m not even trying to defend Github here, but I think under certain circumstances the problems are self-made or just don’t apply to all the users. I don’t see a fundamental difference to codeberg, it’s mostly what you make of it. Maybe I’m just not a maintainer/collaborator of a big enough project that I don’t see the problems.
That said, I don’t plan on closing my account there, it’s just too useful to collaborate because the majority of projects is there. But I’ve mostly not migrated off because of laziness and no urgency to do so, I’m very much against the centralization and MS stewardship.
Personally, I use github for nixvim because, like it or not, that’s where most people are, and for a project that actively values contributions, that just means that using GitHub means more people, which means more contributions, which means more features, which means a better project.
And as for the GitHub workflow, well… I find it’s the easiest one for me, as a maintainer. Maybe it’s easier to send patches using
send-mail, honestly I’ve never tried it, but I already struggle with keeping up enough as-is when going through GH’s notifications, if I had to have a whole email-based workflow which involved me reading and manually merging patches… I’d get absolutely nothing done. Also, nice features like CI and approval requirements on PRs means that I can be sure that code that I merge won’t cause any issues.woah there nelly
Heh you know what I mean, obviously don’t want outrageous feature creep, but given this is a set of configuration modules for Neovim plugins, the more plugins supported the better, as long as there’s quality (which I’ve found GitHub’s workflow helps me maintain)