Why SQLite Does Not Use Git
SQLite (via Hacker News):
And it is not really about just finding the descendents of a check-in from time to time. The fact that descendents are readily available in Fossil means that the information pervades the web pages provided by Fossil. One example: Every Fossil check-in information page (example) shows a small “Context” graph of the immediate predecessor and successors to that check-in. This helps the user maintain better situational awareness, and it provides useful capabilities, such as the ability click forward to the next check-in in sequence. Another example: Fossil easily shows the context around a specific check-in (example) which again helps to promote situational awareness and a deeper understanding of what is happening in the code.
All of the above is possible with Git, given the right extensions and tools and using the right commands. But it is not easy to do, and so it rarely gets done. Consequently, developers have less awareness of what is happening in the code.
[…]
Git keeps the complete DAG of the check-in sequence. But branch tags are local information that is not synced and not retained once a branch closes. This makes review of historical branches tedious.
As an example, consider display of a single historical branch of SQLite as rendered by GitHub and by Fossil:
Update (2018-04-15): See also: Hacker News.
