[teknolog]

Your dev environment is so resource constrained that the size of the repo is a factor?

[samatman]

There are a lot of things which make Fossil attractive for solo and small developers.

An example would be the excellent diffing tools accessible through localhost, as well as things like issue tracking, which git doesn't understand as a concept.

There were some deal-breakers for me (kind of esoteric) and I switched back to git, but not without some annoyance.

[afiori]

The web interface is one of the main benefits in my opinion, especially if you develop on wsl2, on a server, or inside a container.

[bayindirh]

Some of us likes to optimize for footprint, and that's OK.

I run an OrangePi Zero with 512MB of RAM as a home server since it both works and is a fun experience.

[riskable]

On Windows git performance isn't the greatest due to the sheer number of tiny little files (NTFS is absolutely awful). If you have a lot of small commits the number of tiny files grows and grows and grows and git can feel really slow compared to something like fossil. Especially if you're regularly copying your repo from one filesystem/machine to the next (without compressing it into something like a .zip first).

[stjohnswarts]

You can't run "git gc" sporadically on your repo?

[72deluxe]

I have 11809 files in my repo. Opening a git tool (GittyUp) on this repo takes minutes but seconds on Fossil (on a Pi4 with USB3 NVMe).

I use Windows + Linux machines + Pi and share between them so don't use the Pi4 exclusively but have noticed a difference in its ability to handle and open the repo.

[gwbas1c]

At times a single large file is easier to handle than many small files.

Ever try and copy the .git part of a git repo? When it gets big, the copy gets bogged down by the sheer number of files.

[pritambaral]

If you do a git clone locally (yes, git clone works with local paths) you can get all git objects packed into a single .pack file). The pack file may also deduplicate unchanged portions of tracked files. You can even do a shallow clone to reduce the size (and history) of the pack file.

All of this is also possible to do on a repository locally, without cloning.