If only there was a convention for storing PRs and issues and wiki inside the repository itself, similar to how Fossil[1] does it.

Then all the GitHubs and Gitlabs of this world would be limited to just providing UI and would be unable to hold our data hostage by design.

[1] https://fossil-scm.org/home/doc/trunk/www/index.wiki

▲

rwl an hour ago | parent | next [-]

I started using fossil recently and have been quite pleased with this aspect of it. I miss a few things from the git world (mostly magit and its magical ability to stage individual hunks of a diff) and there are a few rough edges, but I totally agree that having a wiki and issue tracking inside the repository makes so much sense. fossil‘s simplicity is a breath of fresh air for anyone who has to use git from a CLI. Well worth a try for anyone on the fence.

▲

zhynn 2 minutes ago | parent | next [-]

I love Fossil, I have been using it for all of my projects for the last couple years. Things that I love include:

1. batteries included single-file functionality (fossil binary + sqlite file and I have everything!) 2. Hosting them is super easy, I have a lighttpd server configured to do cgi-bin, and i just pop the project.fossil file onto the server and I have a project.

The biggest friction is managing users across repos. Each repo is its own RBAC, the "zhynn" user in one repo is not the same as the "zhynn" user in another repo. It would be cool to be able to sync users across repos, which should be possible with sql, but I think that it could get weird with repo-specific permissions. Currently I just add my user to each new repo, granting that user setup permissions, and removing the admin before I scp the .fossil file up to the webserver.

In the end though, and I intend to use it for all of my personal projects from here out.

I have a pipe dream of turning a fossil repo into a portable distributed more-async-friendly slack clone, where the "chat", "wiki" and "forum" functionalities are all used as the back-end for a responsive UI that basically does the same thing that slack does, but lives in a single sqlite file + binary. It could run mostly offline in a kind of scuttlebutt/limited connectivity pattern (when online push/pull messages, get latest chats/files/etc, go back offline. As you go through the content, make your responses locally, then go back online, push/pull again, repeat.)

▲

sssilver 41 minutes ago | parent | prev [-]

The workflow is paradigmically different, and that may throw many people off.

There's no rebase, on principle. Branch names are permanent attributes of commits. Even abandoned branches remain visible forever. Code review is post-hoc.

People who are extremely accustomed to Git workflows may find the paradigm alienating.

	▲	rwl a few seconds ago \| parent [-]
		Yep, it’s not for everyone, and their docs are pretty clear about that. OTOH those same docs contain a variety of arguments that git isn’t really designed for everyone either and that fossil might be a better fit for projects that have just one or a handful of developers, which AFAIK is the vast majority of projects on Github. My experience is that it is certainly an adjustment but the docs are good at explaining (and justifying) the differences, and the built-in features are very useful, especially for anyone looking to reduce their dependence on a centralized host that’s become unreliable.

▲

paularmstrong 36 minutes ago | parent | prev [-]

I've used git-bug[1] for issues and it works pretty well. The web-ui is lagging behind and PR support would be everything you'd need to ditch a central-hosted web instance.

[1] https://github.com/git-bug/git-bug