4 ms·

How about Github without a big corporation? Not controlled by Cloudflare, ddecentralized and uncensorable. Like bittorrent, but for git repos, issues, etc.

RyanAF7 7y ago
You rebel scum...
- deleted 7y ago
  [deleted]
DoctorOW 7y ago
Gitlab is a pretty decent Github competitor that certainly isn't a BIG corporation.
- rat9988 7y ago
  Huh? So we are going to jump on smaller corporations, make them bigger and leave them for a smaller one? I believe the keyword in his idea was decentralized. Disclaimer: I don't care personally.
  - Phrodo_00 7y ago
    It's not federated, but since gitlab is open source and you can run your own instance, you could call it distributed
maemilius 7y ago
So... git? It's already designed to be decentralized. Hosting a public read-only repo would be as easy as standing up NGINX and pointing it at your repo folder, afaik. At my previous job, we all had individual dev machines that we each had accounts on. So, we each had a copy of our repos that we could push to/work from. I wrote a little git alias that would add remotes for each others' machines so we could pull directly from each other (though we couldn't push). Hell, even a "private" git repo wouldn't be too hard as long as you don't care about per-project permissions. Just make a user (e.g. 'git') that has read/write access to the folder and add some SSH keys to authorized_keys. Shazam, you have a private, self-hosted git repo at ssh://git@yoursite.com:path/to/repo.git.
- rakoo 7y ago
  Bare git only stores code, not issues, tickets, wiki, and all the stuff that goes beyond source files. There are a myriad of open source solutions for this, but there is no standard format that allows easy migration and inter-linking.
  - roblabla 7y ago
    Well for wiki, usually a branch containing markdown will transfer well across forges. Issues and PRs are the real issue. I’ve been hoping git appraise would get supported by the forges for distributed PRs, but it doesn’t look like that’ll happen. Gitlab is implementing MRs via git send-email though, which is part of an epic to federate Merge Requests: https://gitlab.com/groups/gitlab-org/-/epics/260 https://gitlab.com/groups/gitlab-org/-/epics/260 .
    - rakoo 7y ago
      Very interesting that gitlab is standardizing on the de facto standard of patch requests! How ironic it is that the existing git-request-pull isn't used more than needed thouh
  - tracker1 7y ago
    would be easy enough for a branch of "issues" containing a number, index.json and ####.md where the number is the initial issue and comments, with some front-matter to associate user details.
    - tracker1 7y ago
      To be clear, there would be directories, each directory being the next incremental number representing the issue number, and the directory containing numbered markdown documents with yml front matter starting at 0 being the root of the issue thread. I'm kind of surprised it isn't already like this, or similar.
- tracker1 7y ago
  you can do the SSH with individual users even... :-) used to do this a lot.

RyanAF7 7y ago

You rebel scum...

deleted 7y ago
[deleted]

DoctorOW 7y ago

Gitlab is a pretty decent Github competitor that certainly isn't a BIG corporation.

rat9988 7y ago
Huh? So we are going to jump on smaller corporations, make them bigger and leave them for a smaller one? I believe the keyword in his idea was decentralized. Disclaimer: I don't care personally.
- Phrodo_00 7y ago
  It's not federated, but since gitlab is open source and you can run your own instance, you could call it distributed

maemilius 7y ago

So... git? It's already designed to be decentralized. Hosting a public read-only repo would be as easy as standing up NGINX and pointing it at your repo folder, afaik. At my previous job, we all had individual dev machines that we each had accounts on. So, we each had a copy of our repos that we could push to/work from. I wrote a little git alias that would add remotes for each others' machines so we could pull directly from each other (though we couldn't push). Hell, even a "private" git repo wouldn't be too hard as long as you don't care about per-project permissions. Just make a user (e.g. 'git') that has read/write access to the folder and add some SSH keys to authorized_keys. Shazam, you have a private, self-hosted git repo at ssh://git@yoursite.com:path/to/repo.git.

rakoo 7y ago
Bare git only stores code, not issues, tickets, wiki, and all the stuff that goes beyond source files. There are a myriad of open source solutions for this, but there is no standard format that allows easy migration and inter-linking.
- roblabla 7y ago
  Well for wiki, usually a branch containing markdown will transfer well across forges. Issues and PRs are the real issue. I’ve been hoping git appraise would get supported by the forges for distributed PRs, but it doesn’t look like that’ll happen. Gitlab is implementing MRs via git send-email though, which is part of an epic to federate Merge Requests: https://gitlab.com/groups/gitlab-org/-/epics/260 https://gitlab.com/groups/gitlab-org/-/epics/260 .
  - rakoo 7y ago
    Very interesting that gitlab is standardizing on the de facto standard of patch requests! How ironic it is that the existing git-request-pull isn't used more than needed thouh
- tracker1 7y ago
  would be easy enough for a branch of "issues" containing a number, index.json and ####.md where the number is the initial issue and comments, with some front-matter to associate user details.
  - tracker1 7y ago
    To be clear, there would be directories, each directory being the next incremental number representing the issue number, and the directory containing numbered markdown documents with yml front matter starting at 0 being the root of the issue thread. I'm kind of surprised it isn't already like this, or similar.
tracker1 7y ago
you can do the SSH with individual users even... :-) used to do this a lot.