51–60 of 107 posts
Then collaborating peer forges could clone the info straight from git and submit changes etc. I think git already has all the sharing tools necessary, what is needed is standards and converters.
Contemplating this through the lens of simply using email and git (ala Linux) to share, review and consume patches, among other things, I can't help but conclude that ultimately this is all totally fucking ridiculous. Sure, it's cool I can send a merge request to another server whatever, but... why are we like this
Contemplating this through the lens of simply using email and git (ala Linux) to share, review and consume patches, among other things, I can't help but conclude that ultimately this is all totally fucking ridiculous. Sure, it's cool I can send a merge request to another server whatever, but... why are we like this
Because people don't know about https://sr.ht
Earlier quoted context omitted.
A lot of this could be solved with better tooling on your side, starting with a better mail reader. Mail readers have supported threading since before many of us were born. You don't have to follow an entire mailing list to follow a thread. I know we have to use normie mail readers for general communication but why are people so averse to using a proper mail set up when it makes sense, like for software development?…
So your advice is to reinvent to very good and battle tested wheel of GitHub and GitLab around multiple different extra tools which don't even come close? Do you also DIY your dishwasher with an assembly line, a rotating robotic arm with a sponge, industrial chemicals? Or do you just use an off the shelf dishwasher if you're at the sufficient scale needed for one?
GitHub isn't analogous to a wheel. GitHub is a proprietary service owned by one company. Any patent on the wheel has long expired.
Earlier quoted context omitted.
I like the user experience of forges far more than email clients. (1) It's hard to track the development of a patch in mailing lists unless you actively follow it. Sometimes there will be a v7 patch but it gets buried in the sheer volume of other emails in the list. Sometimes discussions continue in the v6 thread while others occur in v7 so you have to track _both_ threads. And god forbid people changing subject line…
> (1) It's hard to track the development of a patch in mailing lists unless you actively follow it. I would add that if you automatize it somehow , then you don't "just use e-mail", but you have a different protocol for it (over email in this case).
Earlier quoted context omitted.
So your advice is to reinvent to very good and battle tested wheel of GitHub and GitLab around multiple different extra tools which don't even come close? Do you also DIY your dishwasher with an assembly line, a rotating robotic arm with a sponge, industrial chemicals? Or do you just use an off the shelf dishwasher if you're at the sufficient scale needed for one?
> So your advice is to reinvent to very good and battle tested wheel of GitHub GitHub isn't analogous to a wheel. GitHub is a proprietary service owned by one company. Any patent on the wheel has long expired.
Contemplating this through the lens of simply using email and git (ala Linux) to share, review and consume patches, among other things, I can't help but conclude that ultimately this is all totally fucking ridiculous. Sure, it's cool I can send a merge request to another server whatever, but... why are we like this
But why do you need email if git is already built for decentralized communication? That's the core of the problem. Just add the ability to ask for pull requests, to comment, etc into git and nobody will build those insane protocol-on-top-of-a-protocol-to-communicate-with-a-side-protocol monstrosities.
That's a major understatement. To "just" add this into mainline git, you'd essentially need to either fork git itself in order to add these features or figure a way to add this without making breaking changes, and then convince git maintainers that your PR is worth adding, and then convince enough people to actually use this new standard in place of what they already have (which will also need them to integrate this with their existing forge infrastructure to mitigate XKCD Standards).
Earlier quoted context omitted.
> For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous. For me as a person who learned programming before the Internet was a thing, and has worked both on projects that do patches by email and on projects that use web-based pull requests, I also prefer the web-based pull requests in every possible way. The email based workflow is b…
I think we can all agree that the main reason why developers require distributed source control is in order to facilitate development in a parallel way. So, as a maintainer the purpose of such a request for collaboration (it being a PR or a patch) is to determine if: a) it does what it's expected out of it, b) it matches the conventions of the existing code. I, personally, can make a judgement about both of things be…
How come? How is a text .patch file easier in this regard than a UI for essentially that same .patch? Can't you check out the PR in the same way you would 'apply' a patch to review it?
For what it's worth, you can just add .patch onto the end of a github PR URL to get that.
This is fantastic. I stick my personal projects on GitLab and Codeberg - but if I want people to contribute, I use GitHub; that's where the people are. GitHub has a number of weird repos from popular projects which are just copies of other repos. You can look, but you can't touch. (WordPress and Linux are the big ones). It would be brilliant to look at a project in my preferred UI and raise issues / PRs without havin…
It would be awesome to see Git becoming decentralized again but what's the likelihood of GitHub implementing this?
IIRC Meta now has to implement interoperability with other chat apps like Signal, I wonder if GitHub will have to do the same through AP soon
Earlier quoted context omitted.
A lot of this could be solved with better tooling on your side, starting with a better mail reader. Mail readers have supported threading since before many of us were born. You don't have to follow an entire mailing list to follow a thread. I know we have to use normie mail readers for general communication but why are people so averse to using a proper mail set up when it makes sense, like for software development?…
So your advice is to reinvent to very good and battle tested wheel of GitHub and GitLab around multiple different extra tools which don't even come close? Do you also DIY your dishwasher with an assembly line, a rotating robotic arm with a sponge, industrial chemicals? Or do you just use an off the shelf dishwasher if you're at the sufficient scale needed for one?
My advice is to develop your own personal tools in such a way that you can handle all kinds of interactions with other developers and projects. It's pointless saying "I prefer this or that" when you probably don't get to make those decisions. Projects develop workflows and common tooling like forges for practical reasons. But you, as an individual, shouldn't be tied to any one of them.
My point isn't at all about trying to switch projects from forges to email based workflows, it's merely saying that you can do things to improve your tools such that you can interact with those projects. If you find it difficult to work with a successful project with many contributors then you are the problem, not them.