>>> The principle maintainer of SQLite cannot function effectively without being able to view the successors of a check-in. This one issue is sufficient reason to not use Git, in the view of the designer of SQLite

Ok I'll bite. Why?

I can see it's a nice idea - but at some point you add function X, then ten check ins modify that function. what's the difference between looking back at ten and looking forward at ten?

Perhaps I need an example.

If I remember rightly fossil was written by the Sqllite people? I tried it out for a while back in the day - I think it had this store the tickets in the branch alongside the code - it was an appealing idea, but got complicated quickly.