I use Fossil. It has some advantages:

1. Hashes are computed without adding any additional headers, so it will be the same as computing the hash normally.

2. The /raw capability is a good thing to have.

3. The deck format is not bad.

4. The command-line interface is less confusing than git.

5. It is written in C.

It isn't perfect, but it is more than good enough. (If I do have to change it, I would do "Generalized Fossil" (I already wrote the specification, although no implementation exists yet as far as I know), which will have the same five advantages listed above, and is compatible with the same /raw capability and deck format of existing Fossil repository, too (except old technote edits, but fortunately I do not have any).)

I've read this comment a few times and even unsuccessfully googled /raw and deck format, and this still sounds like GPT-3 to me.

Fossil does not call it the "deck format", although libfossil and Generalized Fossil both do so. The /raw interface allows accessing a raw file (including decks) by its hash or branch name, over HTTP(S).

See [0] for the Fossil deck format. (Generalized Fossil uses the same format, but any combination of cards is allowed, as long as there is exactly one Z card, and not more than one W card; they must still be in the correct order with no duplicates. There are many other details too (e.g. "subrepositories", which can allow you to optionally make decks unparseable in some subrepositories), most of which will not be mentioned in this comment, but I will say that it is mostly a superset of the ordinary Fossil format, except that ordinary Fossil allows cards to be in the wrong order in some circumstances (specifically, technote edits in some versions) that Generalized Fossil does not allow.)

See [1] for an example of the /raw interface (in this case, a mirror of one of my own projects; however, this will work on any publicly accessible Fossil repository). The name "trunk" at the end of the URL is the branch name; you can compute the SHA-1 hash of the returned file and substitute that in place of the word "trunk", and you will get a permanent link to that version. The lines starting with F are the files in that version; each line has the file name, and then the hash, and sometimes another field specifying file mode ("x" means executable). Substituting the hash of the file in the end of the URL will access the contents of that file. The line starting with P has the hash of the previous version; you can put that in the URL to access the previous version.

(In at least one case, I have used this /raw capability to download a single version of a Fossil repository. It is a simpler interface than using /xfer, if you do not have Fossil installed on your computer.)

[0] https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki

[1] http://chiselapp.com/user/zzo38/repository/freeheromesh/raw/...

They wrote the whole thing in C?! Wow, I really admire people who can turn C into useful, complex projects... I was trying to write C the other day and holy shit, it's incredibly hard to write anything that involves more than a couple of files... it just has almost no abstractions and one small slip and you've got a segfault that terminates your program without trace :D I gave up very quickly and been learning Zig now... as low level, but extremely saner to write stuff.

Anyway, why would I usee Fossil rather than Git exactly? Are there code hosts that support it? It does look interesting, but I don't see the motivation to do it when so many hosts support git (people who think GitHub is the "only" host need to look around: there's literally dozens of options), and I'm quite ok using it specially with intelliJ and magit (emacs) support.

> Wow, I really admire people who can turn C into useful, complex project

If you use any open source operating systems a significant portion of software you interact with are C (kernel, shell, utilities, sqlite etc).

I'm well aware... but still, when I see new software written in C when there are so many languages available (which was not the case when Linus started writing Linux) it's amazing to me, both because they can actually do it (I definitely don't have the discipline to pull it off, spoiled too much by high level languages) and because they didn't just choose to use something easier like Go or even Java.

C isn't that hard; you certainly have to approach things in a pretty different way, and it does have a slower curve to productivity, but once you get past the hurdle of having less abstraction (i.e. mostly by just not making pointless abstractions, and having general utilities for the cases you do need some) and learn "gdb -ex r ./program <enter> [wait for crash] bt <enter>" to get a stacktrace, it's, give or take, usable.