3 ms·

Because of so many GitHub problems, I'm adding GitLab.com and Codeberg.org. Setup is simply 3 steps: 1. Sign up on each service, ideally with the same usernam

by jph 4mo ago

Because of so many GitHub problems, I'm adding GitLab.com and Codeberg.org. 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/*

satvikpendem 4mo ago
I'd also add tangled.org and radicle.dev. I've been looking into these new decentralized forges recently.
jvanderbot 4mo ago
And for fun, just spin up a VPS and initialize some bare repos there.
- john01dav 4mo ago
  What's the purpose of using EC2 over something much cheaper, like OVH, digitalocean, or Hetnzer? 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.
  - jvanderbot 4mo ago
    Oh, EC2 is mostly a catchall for VPS for me. Sorry, that's unclear.
guessmyname 4mo ago
Where do you keep Issues, Pull Requests, Wikis, Discussions, project boards, and everything else? (rhetorical question.) 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.
- dijit 4mo ago
  (I upvoted you, for asking the real questions, but to answer) > 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.
  - hluska 4mo ago
    I don’t get it. That’s a lot of failure points to incur in the name of flexibility.
  - rsyring 4mo ago
    > In proper tools that are designed to solve a specific need, not try to do everything: badly. 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).
    - skydhash 4mo ago
      > 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? 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.
kg 4mo ago
Somehow I never knew that you can have multiple push URLs for a single remote. Thank you for sharing this, I've been manually pushing to two remotes with a script for years!
cookiengineer 4mo ago
Hey, that's my workflow! 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 https://github.com/cookiengineer/git-identity [2] https://cookie.engineer/projects/development/git-identity.html https://cookie.engineer/projects/development/git-identity.ht...
redlewel 4mo ago
At this point why not just host your own gitea or something.
rurp 4mo ago
I switched my personal projects to Codeberg recently and couldn't be happier. After spending lord knows how many hours wading through cluttered buggy interfaces in Github it's a pleasure to use a clean intuitive platform. 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.
tonymet 4mo ago
yes let's fix the lack of capacity by 3x'ing the demand to take down all of these other volunteer services , too

by jph 4mo ago

satvikpendem 4mo ago

I'd also add tangled.org and radicle.dev. I've been looking into these new decentralized forges recently.

jvanderbot 4mo ago

And for fun, just spin up a VPS and initialize some bare repos there.

john01dav 4mo ago
What's the purpose of using EC2 over something much cheaper, like OVH, digitalocean, or Hetnzer? 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.
- jvanderbot 4mo ago
  Oh, EC2 is mostly a catchall for VPS for me. Sorry, that's unclear.

guessmyname 4mo ago

Where do you keep Issues, Pull Requests, Wikis, Discussions, project boards, and everything else? (rhetorical question.) 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.

dijit 4mo ago
(I upvoted you, for asking the real questions, but to answer) > 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.
- hluska 4mo ago
  I don’t get it. That’s a lot of failure points to incur in the name of flexibility.
- rsyring 4mo ago
  > In proper tools that are designed to solve a specific need, not try to do everything: badly. 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).
  - skydhash 4mo ago
    > 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? 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.

kg 4mo ago

Somehow I never knew that you can have multiple push URLs for a single remote. Thank you for sharing this, I've been manually pushing to two remotes with a script for years!

cookiengineer 4mo ago

Hey, that's my workflow! 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 https://github.com/cookiengineer/git-identity [2] https://cookie.engineer/projects/development/git-identity.html https://cookie.engineer/projects/development/git-identity.ht...

redlewel 4mo ago

At this point why not just host your own gitea or something.

rurp 4mo ago

I switched my personal projects to Codeberg recently and couldn't be happier. After spending lord knows how many hours wading through cluttered buggy interfaces in Github it's a pleasure to use a clean intuitive platform. 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.

tonymet 4mo ago

yes let's fix the lack of capacity by 3x'ing the demand to take down all of these other volunteer services , too