Need free long-term git hosting

[Jason Yundt]

On 7/2/22 12:53, Rémi Rampin wrote:

> 2022-07-02 12:14 UTC-04, Jason Yundt <jason at jasonyundt.email>:
>
>     If you still want gratis hosting, then I would recommend pagure.io
>     <https://pagure.io/>.
>
>
> Hi everyone,
>
> I'm really loving all those open-source and non-profit-hosted 
> alternatives. I think however that the "long-term" aspect is a 
> problem. How do we make sure software hosted outside of GitHub/GitLab 
> (or even there) won't be lost due to a single hard drive failure, a 
> single person not paying their bill, or the host losing interest (or 
> the author force-pushing by mistake, etc).

Here’s something to consider: Git itself is a backup solution. When you 
clone a repo, you’re creating a complete backup of its entire commit 
history. In the event that a hosting provider suddenly disappears, there 
will probably be at least one person who has an up-to-date clone of the 
repo. This means that we only really need to worry about the parts of a 
project that aren’t stored in its repo:

 1. release assets,
 2. change logs,
 3. which account controls the GitHub/GitLab/whatever repo,
 4. the project description,
 5. issues,
 6. pull requests/merge requests/patches,
 7. CI logs,
 8. security advisories and
 9. community discussions.

If you want to make sure that those things don’t disappear, then you 
should make sure that they’re in your repo. If we remove from that list 
everything that could reasonably be kept in the main repo, we’re left with:

 1. release assets,
 2. issues,
 3. pull requests/merge requests/patches,
 4. CI logs and
 5. community discussions.

If you’re concerned about losing any of those things, then you can store 
them in a public-inbox <https://public-inbox.org/README.html>. 
Public-inboxes are sets of Git repos that contain mailing list archives. 
Anyone can mirror public-inboxes 
<https://public-inbox.org/public-inbox-overview.html>, although, in 
practice, lots of people clone the main repo, and few clone the 
public-inbox repos. If you want to check out public-inbox in action, 
take a look at lore.kernel.org <https://lore.kernel.org/>.

Additionally, there’s a peer-to-peer network/protocol named Radicle 
<https://radicle.network/> that stores patches (their version of pull 
requests) as annotated Git tags and disseminates them throughout the 
network. They plan to do something similar for comments and issues, but 
I don’t think that those are implemented yet. I tried out Radicle a 
while ago, and it was painful to use. I’m assuming that things over 
there are still very early days.

There’s also ForgeFed <https://forgefed.org/> which would (presumably, 
IDK) replicate data across multiple forges. Even if ForgeFed doesn’t 
store complete backups on other forges, you would still be able to have 
a pull request fork on another forge. Doing so would decrease the 
chances that the repos history disappears from the Internet (even if the 
repo’s original address stops working).

Also, if you’re not particularly attached to Git, then you could try 
Fossil <https://www.fossil-scm.org/home/doc/trunk/www/index.wiki> which 
has built-in distributed issue tracking. I don’t know what its 
equivalent of pull requests are.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/give-up-github/attachments/20220702/7d883b2a/attachment.html>