Forgejo and Codeberg are great (I use both), but only for backups, at least unless you’re already well known. For small developers, GitHub is pretty much the only platform that might let others discover your project.
Github will never be the only options there’s always alternatives.
But none that compete properly with it. I’m not a good programmer but nearly every open sourced project I’ve used/accessed was on Guthub
It was a shit show before GitHub. I used to email code. I used to have to find random IRC rooms, follow random contributor guides, or beg for access. I remember one project required me to download some torrent bullshit just so I can submit my patch.
As a contributor, I can’t go back to creating multiple accounts and trying to figure out how the hell I give you code.
I don’t care if GitHub is the defacto for open-source projects, as long as there are competitors and mirrors.
I understand and agree. My concern is just the gap between it and the competitors.
I don’t get the first part on pull requests, you can’t just say:
I’d like to see what other tools people can offer. Perhaps a tool that promotes ensemble working to share the problem solving and context with a larger group.
and then also say:
I do not know what these tools are or what they look like, and I’m not saying Pull Requests are all bad either. But I don’t believe that we’ve found the one-and-only way to work together on a code base.
You have to make a valid proposal to say how the workflow could be “improved” (if it really can be), otherwise we’re talking about nothingness, the draft that is written in the middle is very vague IMO, what I’m really missing is what are the specific problems in the PR process, you say:
Pull Requests are a blunt instrument that puts gate keeping front-and-center
It’s true and I don’t see how things can work otherwise, the point made in the linked article (emphasis mine):
If I am messing about with something I have low confidence in, I will be very explicit in how I ask for help. Preferably at a much earlier stage than in opening a PR. But if I have high confidence in my code change, I would love for you to take a look, but I don’t expect you to spend too much time figuring it all out.
Confidence is completely subjective, some small change that you are confident will touch that place and only that, might well affect other parts of the code that you don’t know about, and who knows about it? The people that have worked on that code. I’ve worked a lot on a codebase where the main developer stepped down from his role to do managerial tasks and he doesn’t perform any code review at all mainly because the company doesn’t value the review process, so there’s no time for it, but also, even if there was, he can’t remember anything he’s written.
So it’s not rare that I touch some code, approve it myself and a user notices that something broke once it has hit production, I was confident in the change I made and I was wrong, I couldn’t have known that because I didn’t have the full knowledge of the codebase.
When I’m not confident, I usually ask and get a little feedback, it usually helps, but it’s not exhaustive, so some issues might crop up anyways, even still, I might be working on something I created and be confident, but my mind was hazy at the time of making the changes, so I make mistakes anyway.
That’s why I believe that a strict review process is always beneficial, even for supposed “stupid” changes, because you’re not editing a document, you’re editing code that will run, a mistake somewhere has effects elsewhere and wrong code has no place hitting production if it can reasonably be prevented, those “small hotfixes” that are urgently needed to fix that broken thing in production will often lead to some other issue somewhere because you were pressured to think fast and get out a dirty solution which will likely cause some problem you hadn’t foreseen in your supposed confidence further down the line.
What do we have on the other side, collaborative editing? A live feed of what the others are doing so anyone in the team can step in to help? That’s spreading the attention of the experienced developers that I imagine would be involved in this collaboration too thin, they would have to waste time thinking what the mental process of the other developer is, even in an interrupted stage, where everything is up in the air, that is huge cognitive load, it makes way more sense to put that load on the single developer that has to refine their work until it’s presentable, then, if they run into some problem midway, they will usually ask questions on logic and architecture, more so than code, and even if it is about code, their current codebase state can be pulled from their repository object of the PR to try outI have a private instance of forgejo on my dedicated server and use codeberg for public facing stuff. it’s great. I wish MORE FOSS stuff got off github. Like Searxng for example. I have a Searx instance set up also but I can’t add it to the searxng list on github because I refuse to sign back up with them. there are a few others like that.
Also if you have the means to afford it consider donating to Codeberg.
I have a Forgejo instance with all my private repositories and use GitHub for my public repositories I want to share with others / collaborate on. I’m planning to switch to Forgejo / Codeberg for my public repositories when Forgefed has been implemented.
Gitea is awesome and fairly easy to get up and running.
I already set up my own forgejo instance and moved my code off of GitHub:
Love codeberg for personal, already move our business to gitlab
I just set up a private forgejo instance and it was really quick and easy. So far I’m enjoying it.
Yeah. Got a raspberry pi sat by our router, being the home dns server and fileshare. Installing forgejo was a one-liner, configuring nginx to serve it over https took about half a dozen. Very easy, perfectly reliable.
I agree we need more diverse options to host source code projects with. I remember when people moved their source code to other places like gitlab when github was bought by microsoft.
Codeberg has a git “ci” possibility (woodpecker?). What is missing?
People. Most people are still on GitHub and don’t see things on Codeberg / GitLab nor are they willing to create an account. It’s a classic case of the network effect.
Exactly. I’m looking forward to forgejo federation.
Not all actions run on it.
Also, GitHub infrastructure is free and really performance, that’s why I use it even if I have my own for server.
Also, discoverability. For the projects that I want to show to the world, GitHub is best, since it’s most likely people see it there.
Free like in Microsoft free…
For the discoverability I totally understand, but it’s a behemoth, it should be split up IMO.
On a side note, I have never had any performance problems with Codeberg, but my projects aren’t that big.
Selfhosted ci works well, but the GitHub ci is so fast it’s not even funny. At least compared to my selfhosted stuff which is arguably cheap
Jujutsu is another git alternative I keep seeing around and came to mind reading this:
https://steveklabnik.github.io/jujutsu-tutorial/introduction/what-is-jj-and-why-should-i-care.html
I gave a try to jj. It’s fine for personal projects or small team and make the workflow a bit easier. No more “git add; git commit; git push” each time you do a modification. You just “jj git push” and everything will be automatically pushed.
However, the biggest criticism I have is that he doesn’t encourage to push every time. It really encourages you to keep your modif locally and push only to create a PR, and that’s not a good approach.
Even if you code is WIP, even if everything crash, you really should push your code to backup it. Who cares ? As long as it is not on master branch, it’s your own mess.
Why? This is isn’t about git. It’s about github. Two completely different tools.
I know. The author suggests:
Experiment with new-to-you version control systems like Fossil, Mercurial, and Pijul.
The author is:
learning about different version control systems. For example, the differences between Fossil and git revealed a lot of my biases towards git simply because it’s familiar (and Fossil seems really cool). Reading about the theory behind Pijul absolutely bends my brain into knots. I keep trying anyway because conflicts in git are frustrating and I’d like a better solution.
The author says:
It would be nice to move beyond git one day and have a better experience for managing complex codebases, and not on GitHub’s timeline.
I think it’s valid unless one thinks git should be the only standard. Looking at other tool chains opens options
Jujutsu is a Git frontend, from what I understand, much like there’s tons of Git GUIs. So, you interact with it in a different way, but you still push to a Git repository and others can interact with your code by using Git.
I guess, it somewhat lessens the grip of Git, because they can hook different backend services (e.g. Subversion, Mercurial, Fossil) into this frontend, and from what I understand, they plan to develop an own backend eventually. But yeah, for now, the communication standard is still Git.
It’s not a Git frontend per se, it just uses Git as a storage layer (Google’s internal backend doesn’t use Git and behaves more like a commit cloud)
deleted by creator
