SQLite Doesn't Use Git

I really like the notion of having the whole repo including issue tracking in a single file that can be easily copied around. But Fossil's stance on history - specifically, the deliberate refusal to implement history-editing functionality like squash and rebase - is a showstopper, and their rationale for it reads very much along the lines of "you're holding it wrong".

SQLite also doesn&#x27;t use CVS, SVN, or Perforce.<p>If this title were &quot;SQLite uses Fossil&quot;, it&#x27;d be more apparently just another ad for Fossil.

Richard Hipp (SQLite guy) spoke about the thinking behind writing Fossil instead of using Git on Corecursive episode 66.<p>If i remember correctly, it wasn&#x27;t that they had any real problem with git, but that git didn&#x27;t really fit with how they wanted to work, so they created their own thing.<p><a href="https:&#x2F;&#x2F;corecursive.com&#x2F;066-sqlite-with-richard-hipp&#x2F;" rel="nofollow">https:&#x2F;&#x2F;corecursive.com&#x2F;066-sqlite-with-richard-hipp&#x2F;</a>

Fun fact: Fossil uses sqlite. And sqlite uses fossil. Think about that.<p>SQLite is what I consider a well-engineered product.<p>And Richard Hipp is an excellent engineer. Listen to his podcast episodes on the changelog. It&#x27;s fun. His mentality is interesting.<p><a href="https:&#x2F;&#x2F;changelog.com&#x2F;person&#x2F;drh&#x2F;podcasts#feed" rel="nofollow">https:&#x2F;&#x2F;changelog.com&#x2F;person&#x2F;drh&#x2F;podcasts#feed</a>

The single file repository is super convenient for one person projects, but just a word of caution to fossil users - backup the repo file often. A while back I downgraded the fossil binary (by accident) and committed a change to a local repo which caused it to be corrupted. It was a repeatable thing, and was annoying at the time, but not a showstopper. I only lost a day&#x27;s worth of work. I wish fossil had done a version check between the binary and the repo to refuse to alter the repo if the binary version was incompatible.

I use Fossil at home since it&#x27;s just me. The single file approach takes up less space than the comparable git tree.<p>Fossil has the ability to push to git, which I do periodically just for curiosity.

With regard to rebase and fossil vs git when you have a small team of trusted developers rebase is harmful because you lose information that could help you understand the _why_ of something. In contrast if you are working with thousands of untrusted developers you need a way to increase the signal-to-noise at the cost of some granularity.<p>This comes about from their development styles (see: <a href="http:&#x2F;&#x2F;www.catb.org&#x2F;~esr&#x2F;writings&#x2F;cathedral-bazaar&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.catb.org&#x2F;~esr&#x2F;writings&#x2F;cathedral-bazaar&#x2F;</a>).<p>- Use fossil if you prefer the cathedral style of development SQLite is open source but does not accept contributions.<p>- Use Git if you prefer the bazaar style of development. You want to accept hit-and-run style contributions from anyone.

To be honest, I hate Git. The commands don&#x27;t really make sense outside some basic stuff. For certain organizational setups it seems like overkill. I am not a full-time programmer but I do programming for my job and for personal projects sometimes and I never enjoy using Git.

Important note mentioned here is that sqlite doesn&#x27;t accept external contributions and has a very small team. The Fossil folks and the sqlite folks are also essentially the same team. Fossil is a boutique VCS which essentially only exists for sqlite.

&gt; I still believe that a squash+merge (or sometimes, rebase) workflow pairs better with pull requests<p>Unpopular opinion, but I find the value of having the actual surrounding context in which the code was developed more valuable than having a flat history.

Author confuses SQLite&#x27;s development model with Fossil&#x27;s at the end, the latter welcomes contributions: <a href="https:&#x2F;&#x2F;www.fossil-scm.org&#x2F;home&#x2F;doc&#x2F;trunk&#x2F;www&#x2F;contribute.wiki" rel="nofollow">https:&#x2F;&#x2F;www.fossil-scm.org&#x2F;home&#x2F;doc&#x2F;trunk&#x2F;www&#x2F;contribute.wik...</a>

I’d use fossil more for personal work if i wasn’t hopelessly addicted to magit.

Anyone use Fossil for professional &#x2F; team development?<p>I&#x27;d love to hear some real-world experiences.

The sound of it from the article reminds me some of <a href="https:&#x2F;&#x2F;trac.edgewall.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;trac.edgewall.org&#x2F;</a>

The SQLite people not using git or hg is like the Bell Labs people and three-button-mouse heavy sam&#x2F;acme: when you’re right about everything 99&#x2F;100 times, that 100th time you’re really going to double down on some dumb-ass thing.<p>In what possible world is telling the most successful set of design decisions about document management in the history of documents or management to get fucked not just “I’ve got goodwill to burn, let’s ride.”? SQLite is indeed badass, but cool it djb, I’m already stressing about the zero bugs ever thing.

Alt title - SQLite doesn&#x27;t Git it<p>Great read :D