[nmz]

I think [0] indicates that it does scale quite well, you can even test by comparing the 2. You can go from cloning to pushing on a repo in half the time. There's branches as well, so while the /timeline[1] seems too busy, you can always drop back to a forum or the bug tracker, which it has already.

  time fossil clone https://fossil-scm.org/
  time git clone https://github.com/drhsqlite/fossil-mirror

My results were

  fossil
   time > real    5m43.120s user    2m56.532s sys     0m48.246s
   ls -lh > 60M fossil-scm.fossil


  git
   time > real    10m35.043s user    5m58.427s sys     1m10.555s
   du -sh fossil-mirror/.git/ > 829M

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

[glandium]

There is something fishy with the repo on github.

  git repack -a -f -d
  du -sh .git
   65M    .git

It's also significantly faster to clone after the repack:

  time git clone --mirror https://github.com/drhsqlite/fossil-mirror
  65.10s user 21.22s system 35% cpu 4:05.92 total

  time git clone --no-local fossil-mirror fossil-no-repack
  26.92s user 2.99s system 155% cpu 19.190 total

  git -C fossil-mirror.git repack -a -f -d
  time git clone --no-local fossil-mirror fossil-repack
  5.42s user 1.18s system 211% cpu 3.121 total

Edit: took new measurements with --mirror on the first clone so that the "local" clones actually get all the branches.

Also:

  git gc --aggressive
  du -sh .git
   42M    .git

[nmz]

I imagine fossils internal git export function is not robust. Even when you {fossil git export} the repo, you still get a much bigger .git than fossil (20mb more), with errors on some checkouts. Repacking doesn't do much either in this case, so the functionality changes.