4 ms·

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 folde

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.

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.