[bch]

I’m a fossil fan.

I’d say that git is fine for 90% of development (or some arbitrarily large number), but so is fossil. I don’t even think that SQLite-in-git would necessarily be a deal-breaker that couldn’t be worked around (drh ‘sqlite can chime in here). The whole space (from personal projects to global collaboration) is diverse enough that there’s no talking about “better” without qualifying the situation, either.

Fossil is good for a large subset of work that can benefit from source control management, regardless of git.

What git definately has is

1) scaleabilty, which is probably of no consequence for 99% of the cases it is employed

2) network effect, for better AND worse

[nebulous1]

> drh ‘sqlite can chime in here

He already has

> With Git, it is very difficult to find the successors (decendents) of a check-in ... This is a deal-breaker, a show-stopper.

[AstralStorm]

Someone still thinks in the single main branch mode. It is sometimes the main case but definitely not in git world.

This operation is not easy in any DAG. It involves:

- find all or desired branch tips - walk backwards until hitting tge desired checkin - memoize already seen parents to not walk them multiple times

[bzbarsky]

Amusingly enough, git's scaleability is also not that great (e.g. worse than mercurial last I checked).

The network effects are there, though.

[AstralStorm]

Please provide the source about scalability. Also what kind of scalability?

[bzbarsky]

Scalability to large numbers of files and large numbers of changesets.

For the large number of files one https://code.facebook.com/posts/218678814984400/scaling-merc... is one source. There's some earlier discussion of the same issue at https://news.ycombinator.com/item?id=3549679 that goes into some technical details.

There has been some work on git since then to address some of those issues (e.g. see https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g... ) but it's not clear to me that it helped enough to catch up to where Mercurial is for large repos.

For large numbers of changesets, just try running "log" or "annnotate" on any file with a long history in git. I just did this simple experiment:

1) hg clone https://hg.mozilla.org/mozilla-central/

2) git clone https://github.com/mozilla/gecko-dev.git

3) (cd mozilla-central && time hg log dom/base/nsDocument.cpp)

4) (cd gecko-dev && time git log dom/base/nsDocument.cpp)

It's not quite apples to apples because the git repo there has some pre-mercurial CVS history in it. But note that I'm not even using --follow for git and the file _has_ been renamed after the mercurial repo starts, so git is actually finding fewer commits than mercurial is here.

Anyway, if I do the above log calls a few times to make sure the caches are warm, I end up seeing times in the 8s range for git and the 0.8s range (yes, 10x faster) for mercurial.

That all said, most repos do not have millions (or even hundreds of thousands) of changesets or files. So the scalability problems are not problems for most users of either VCS.