Setup is simply 3 steps:
1. Sign up on each service, ideally with the same username.
2. For each repo you want to share, create the same repo name as a blank repo; do not automatically create a README.
3. Edit your local file .git/config to add push URLs, then push as usual.
Example:
[remote "origin"]
url = git@github.com:foo/bar.git
pushurl = git@codeberg.org:foo/bar.git
pushurl = git@github.com:foo/bar.git
pushurl = git@gitlab.com:foo/bar.git
fetch = +refs/heads/*:refs/remotes/origin/*These days, the problem with cloud-hosted Git platforms is not where to push your code. Replicating repositories across multiple providers is relatively easy, and Git has always been good at that. The harder problem is that successful teams end up accumulating a lot more than source code around their repositories, and much of that information becomes just as important as the code itself.
Bug reports, feature requests, documentation, design discussions, code reviews, project planning, CI/CD configuration, and years of historical context all tend to live inside platforms such as GitHub. While the Git repository itself is portable, all of that surrounding data is often much harder to migrate cleanly, especially if a team has built workflows and integrations around a particular provider.
That, in my view, is one of the main reasons so many companies are heavily dependent on GitHub. Moving the code elsewhere is usually straightforward; moving the entire development process, with all of its history, metadata, and institutional knowledge, is not. When GitHub goes down, the question is often less about where you can push your next commit and more about how easily you can recreate the rest of the environment that your team relies on every day.
Particularly if your work and the employer/client/org is primarily based on a web project (extra points, you already are managing their auth) then you could simply add a new subdomain or route to your existing web project that serves said self-hosted issue tracker or wiki.
Of course these things can get into the weeds but I do think that given the dramatically reduced turnaround times for a competent dev to spin up and customize in-house/self-hosted solutions for basic things like issues and wikis the strategy is more relevant and prudent than ever.
> Where do you keep Issues,
Youtrack
> Pull Requests,
Gerrit, it's way better for code review
> Wikis,
Also Youtrack, but other software exists that's specific for this, I have seen Confluence used a lot and while I don't recommend: that's usually the case.
> Discussions,
As far away from code as possible, right now it's Zulip
> project boards,
Youtrack, though usually in companies they use Jira for this.
> and everything else? (rhetorical question.)
In proper tools that are designed to solve a specific need, not try to do everything: badly.
--
Now, a sane person will respond to me with the fact that I haven't removed any single points of failure, I've actually just added more of them. They'd be right! The differences is that it makes the stack a bit more flexible and composable. Migration of, say, the Wiki, doesn't make major issues because it's already somewhat decoupled.
And when you want to search for that one thing that you know got documented somewhere, but can't remember where, how many systems do you have to search?
That's one of the reasons I like the code, issues, docs (code or wiki depending), and discussions all in the same repo.
Not to be confused with Chat, which is more ephemeral, and is, for us, in Slack. But we have to be mindful of chat discussions that turn substantive and make sure we copy that info to a Discussion in the repo (which can be annoying to do and annoying when it's not done).
Not GP, but is that actually a real problem? Take a project like OpenBSD where the code, the bug tracking , and the design discussion happens in different place?
Even in reality, you don’t put the workshop in the conference room.
I think it's worthy of a non-rhetorical answer anyways: https://docs.gitlab.com/user/project/import/github/#imported...
None of those might be perfect, but at least people are trying. Even something like Gitea and other forges that you can host yourself have support for most of the basic functionality you'd expect.
However, If we ever wanted a setup where it's easy to mirror rather than import stuff, we'd probably want to look in the direction of storing everything in folders within the repo, e.g. a file/folder for every issue, for every Wiki page etc. Most of the mirroring seems to only concern the repo itself, not the stuff around it, for example: https://docs.gitlab.com/user/project/repository/mirror/
Years ago I was a big fan of Gitlab and always talked them up as a better Github. At this point though they've spent years trying to become just as convoluted and "enterprisey" as Github, but with much less success.
Usually the argument is for scalability, but a single VM for personal use doesn't need that, and even if you do want that, you'll need more than a bare repo.
I also built a convenient CLI tool to switch identities on a per-repository basis. [1] [2] ...which makes working in enterprise environments much easier, as I can just have separate identities/keypairs for each customer.
[1] https://github.com/cookiengineer/git-identity
[2] https://cookie.engineer/projects/development/git-identity.ht...
I remember way back in the "olden days" in San Francisco seeing people with Octocat signs on Market. GitHub was awesome. Fond memories.
But times are a-changin', and for lots of reasons I just don't feel like GitHub is cool or "for me" anymore.
So, with my new Mac Mini, because they were on sale and everyone was getting one for OpenClaw... I put that puppy on my tailnet, installed Gitea, and I've been using it exclusively for all my projects. It's been weeks since I've pushed anything to GitHub.
I feel free.
Only use GitHub for employers at the moment, but don’t intend to put new code there going forward.
I had a coworker talking about how great some AI coding tool is because it can sort a bunch of strings alphabetically for him. This coworker is a programmer. Working with a language that has a builtin sort function.
Does anything wrap up the AI craze more succinctly than boldly calling AI the perfect use case for an already-solved problem?
— Charlie Munger
Edit: great write up, thank you op.
The fact that companies request you to star them on GitHub and the stars can be bought tells you that there is a value in these stars. [2]
Now, some astute reader, who thinks the $1 trillion global advertisement market does not influence them, will also claim that they don't care about GitHub stars.
Well, that's not how the world works.
Fake stars can propel a good project to great.
A lot of people will use GitHub stars as a currency to decide the importance of certain FOSS (or even open-core) projects.
The real lock-in is in GitHub stars [3].
1 - https://blog.nginx.org/blog/nginx-open-source-moves-to-githu...
So, the source is still GitHub, right?
Which means I have to keep my FOSS project on GitHub to accumulate stars.
And how will the project accumulate more?
> everyone knows it's gamed anyway, so why not?
Then why do they still have purchase value?
Microsoft & Github are not a monolith. it's an institution with dozens of divisions and 100k+ employees all vying for revenue.
Anyone who's worked at a big company knows what it's like to be given an unfunded mandate to serve an important business strategy.
The author moans about the 3 copilot button's on github. meanwhile github has to manage (a) providing loads of free hosting and (b) keeping the servers up.
The entitlement to moan about a free app not providing enough free hosting, and bemoan the engineers who are barely keeping it running.
But we have no issues whatsoever with Azure Devops....ever. It's excellent. Seriously.
Does anyone know why the experience between Github and DevOps is so different, if they're supposed merging the two? Or at least seemingly related? Or are they not at all?
Or is it simply because Azure is "enterprise" and Microsoft cares about that more?
Here is a screencap of the wip mobile UI on old safari: https://files.catbox.moe/bo7pxn.jpeg
It’s fascinating to me that the people who know the most about tech keep deciding over and over to give something to some corporation and inevitably it becomes an issue. I guess ease of use and freemium really trumps everything; I expect more from smart people but money talks.
If you do not have a lot of users you can easily set it up too.
Heck, GH Stars are used as a vanity metric for a lot of projects.
Soooo...
Let me preface this by saying this is an old (so things are different) anecdote (which is not the singular of data), but...
a) I had never heard of codeberg.
b) My company used an on-prem gitlab instance, and it sucked donkey dicks.
For example, the equivalent of just putting a statically generated site into github pages required running a fucking production pipe.
You should make the easy things easy and the hard things possible. Making the easy things hard is an immediate red flag.
> The problem is the inertia.
Oh, don't worry about that. Github is working diligently to fix that problem. The question is, are the alternatives worthwhile?
Just because you're a developer doesn't mean you're a hacker or you care for the craft on any level.
The wild west days are over.
There are many things that I don't like about Github, but I think the most important one is that Github doesn't allow users to have multiple free accounts.
You can create as many accounts as you want on Reddit, have as many blogs as you want on Tumblr, and even create multiple personae on Facebook on a single account, but Github doesn't allow you to do any of that.
You can't be a "hacker" platform when you give users less control over their privacy than Facebook provides.
I assume that is a bigger problem when you consider everyone decided to stop hosting their own forum and moving all their discussion to Github issues and Github's built-in forum.
Issues aren't a proper project management tool and wikis aren't fit as documentation.
I've completely abandoned Github.
Unlike sourceforge, how am I suppose to find new stuff when I am rate-limited after a couple of searches?
Which email chains is this referring to? GitHub/community is fairly active from the community perspective. GitHub rarely looks at it anymore, prioritising their Enterprise roadmap.
> Github often breaks on firefox and safari, browsers with millions of users
[[citation needed]].
I’ve been as annoyed as everyone with the GitHub frontend performance since the React rewrite, but never really faced breakage in Firefox. This claim is repeated a few times in the article, but without any links.
Self hosted gitlab is a dream, no surprises ever, exactly how your repos are supposed to work.
And mind you, that's on a small 4 core VM on 2019 mid-range Xeons, which I would not consider to be a huge amount of compute (granted, not Raspberry Pi level, but I'd expect the SD card to be much more of an issue).
So yeah, along with the sane(r) way to do CI pipelines, and usable review tools, it's a net improvement over GitHub.
VS Code doesn't have a similar scaling issue that I see
> This is a lie. Github - and the microsoft organization more widely - clearly prioritize flashy AI features over fundamental reliability Github has a public changelog. In thirty days since they posted their update, their patch notes contain the words “copilot” 59 times, “agent” 8 times, “performance” 0 times, and “reliability” 0 times. The changelog has a feature to filter by category: copilot is it’s own category: performance and reliability do not exist at all.
I suppose when calling someone a liar, it's beneficial to have hard numbers to back it up. Ouch.
We've been using github for a while at our company and find it really good. Copilot reviews are good, we have actions that work every single time, everything just works really well. There are, of course, plenty of things that could be improved, but it's still top dog in this space. I think maybe a couple of times there's been an outage that's affected us for a small amount of time. Overall, it's a good product.
