Why SQLite Does Not Use Git | Hacker News Reader

Why SQLite Does Not Use Git

sqlite.org

66 pointssarupbanskota43 comments

I’ve tried Fossil a number of times, but several oddly-rigid aspects always manage to turn me off. Take, for example, the integrated bug tracker, which is novel and a big draw for me. Say I write up a bug and then notice an error in the description… I can’t edit it! I can merely append more comments, which also can't be edited or removed. The recommendation I found was that I should close (there's no delete!) the bug and create a new one. What’s the point of that level of immutability? I can tolerate the purity for the source code (e.g., the whole no rebase position they've taken), but for project metadata, I need way more freedom.

It’s a cool app that I’d love to use, but there are a few showstopper oddities.

You can't edit descriptions!? I was curious about Fossil but I just noped right out.

Can you share the other issues you encountered? I need to write some notes to my future self for when I stumble upon Fossil again.

Edit:

I couldn't help it and gave Fossil a try just to see what the editing was like. I changed my view.

The "description" you enter when opening a ticket seems to be just an initial comment. So when you edit the ticket, you are able to add new comments, but not edit existing ones like the initial description.

This isn't bad, it's just a different workflow with different tradeoffs. Personally, I'm used to tickets where I can add comments and also update a main Description with the current state of things. That's not how Fossil's ticketing system works though and it's intentional.

I think it would be great for Fossil to have editable comments that are somehow versioned, plus an independent Description field that can be edited and versioned like other fields, but it doesn't. And I don't think they should have to go and add a large amount of complexity to do the versioning of a description field + comments like you (and I) would prefer just because.

So I think you are criticizing the issue (immutable, append-only comments) with partial understanding about how it works and how it compares to a completely different feature you are familiar with in other ticket systems (mutable/versioned description, plus mutable/versioned appendable comments). I do think Fossil has room to improve in this area, however.

> What’s the point of that level of immutability?

That all data even the bug tracker can be synchronized across spacetime without conflicts.

Sure, but parts of the ticket are editable. I can change the title and various fields, and everything gets versioned. But they've elected to not provide an editable description field, and instead, all clarification must be in append-only, immutable comments. This seems like an arbitrary limitation.

Well, files in the project can be synchronized across spacetime without conflicts but you can presumably edit their contents so this is a conscious design decision, not a technical one

It's been 10 years and I still need to look up the most basic things in git. It's just not intuitive to me at all.

Had fossil recommended to me. Also read their fossil vs git page, and I found myself agreeing with everything they said.

https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

For another perspective: It's been maybe 6 years of pretty consistent commandline usage, and I pretty much do not have to look up anything.

I usually do feature branches, so the operations Im talking about are push/pull, commit, merge, rebase, bisect, and cherry-pick. They each have a few flags, and a few positional arguments.

Realistically, they dont have to be intuitive. You learn them once by going through a small book like the git book, and you wont really forget them if you use them regularly.

I recommend doing this.

The checkout/reset concept is severely and confusingly overloaded/overlapping. Addition is confusing as well, although not to that extent.

Changes can be in many states, and many operations can be applied (all the permutations of: in/off index, deleted, changed, added), but the UX has never been (re-)designed for usability, so that it's extremely confusing to remember what to use.

As I said, I have a totally different experience. I never had a day where it 'clicked' or anything, I just feel I understood the model and now it makes sense.

Agreed, I use command line for basic tasks, then git-cola for committing for a basic UI.

Before git I used svn, and must say the main thing I'm happy about git is how easy it is to just push a repository wherever, and GitHub having perfect timing to help it become a staple (at the time they didn't have private repos, but was still good).

I have a whole bunch of shell aliases for my day to day use, mostly around branches (where I work we use GitHub, and opensource projects who use git use branches for PRs/MRs/etc).

It's been 10 years and I don't have to look up most commands in git.

You say the most basic commands, I don't understand how git add, commit, push, pull, fetch would require a look up.

I have to look up how to create and switch to branches every single time.

It's always fascinating when someone building something yak shaves a project of major skill on the way. Both git and fossil would be notable on their own, but the respective authors simply needed a tool for Linux and Sqlite.

Really raises the boundary for what a software engineer can do. Very inspiring.

TeX was also built for TAOCP. Crazy stuff. Really makes me want to write code. Love it.

> TeX was also built for TAOCP. Crazy stuff.

If you haven't yet, read "Donald Knuth - The Patron Saint of Yak Shaves" at https://yakshav.es/the-patron-saint-of-yakshaves/

For TAOCP Knuth also creates a new assembly language, for illustration purposes.

TeX was written in WEB, a programming language Knuth made which transpiles to Pascal.

It's based on literate programming, a programming paradigm Knuth introduced.

And Knuth developed his own font, for use by TeX, along with a system to make fonts.

Crazy stuff indeed!

It happens quite often actually, it is sometimes called a framework, can become a SaaS, ...

Why SQLite does not use Git (2018) - https://news.ycombinator.com/item?id=36830813 - July 2023 (439 comments)

Why SQLite does not use Git (2018) - https://news.ycombinator.com/item?id=29125934 - Nov 2021 (356 comments)

Why SQLite Does Not Use Git? - https://news.ycombinator.com/item?id=26112802 - Feb 2021 (1 comment)

Why SQLite Does Not Use Git - https://news.ycombinator.com/item?id=16806114 - April 2018 (608 comments)

People like to hate Git, but I guess that's because everyone uses it. I'm using Git, mostly with Idea UI, but sometimes with CLI and it's absolutely fine for me. I understand how Git works (the whole concept of commits, parents and so on), I follow some sane rules to prevent commit graph from turning to spaghetti and I never have any issues, it just works for me, 100% reliably.

If you don't go off the well trodden path, git works perfectly well. It's only when you have some special thing you do that is snowflake where you hit issues or unintuitive commands.

I tried to use Fossil for personal projects but it didn’t work for me.

Idea is very appealing but in the end I found way too many distractions, especially in solo dev environment. I also agree that in group Git is standard so introducing something like Fossil might add needles friction.

But I still recommend checking it out. Some concepts are neat and might align with use cases that I don’t have.

Right now I’m experimenting with jj/jujutsu [1] and so far it works locally but I still hadn’t used the Git integration.

[1]: https://github.com/martinvonz/jj

I’ve been using jj for at least 12 months now. Generally, I’ve enjoyed it, but it can be a wee bit dangerous with its very easy historic amendments and its easy force pushes.

That's fair. Since 0.10.0 (~a month ago), there's support for immutable commits. See https://martinvonz.github.io/jj/v0.11.0/config/#set-of-immut....

I use Fossil every day for all my projects and it works great for me. Super easy to self host and has integrated Wiki, bug tracker, ticket system and a server. Very intuitive CLI too.

Highly recommended for indie/small teams.

> Highly recommended for indie/small teams.

Realistically, though, the better choice for small teams is going to be gitlab or github.

Using anything that isn't "boring technology" is going to introduce unnecessary friction and effort, which would be better spent on creating the product, especially given small team size.

Yeah, I'd be wary of using something other than git because if you hire a new graduate, there's a much higher chance that they'll have used Git (and most likely GitHub too) than that they've used Fossil. And most repositories outside your company that you ever need to interact with are most likely Git too.

It's easy to import and export to git: https://fossil-scm.org/home/doc/tip/www/inout.wiki

I argue this would come under

> unnecessary friction and effort

Git does seem to be that.

Or gitea if you want a self hosted option that is lighter and less effort to use than gitlab.

As a web dev, user of 100 different tools to render something to browser, I like how self contained it seems to be.

Previously on HN:

https://news.ycombinator.com/item?id=12673229

https://news.ycombinator.com/item?id=24643200

https://news.ycombinator.com/item?id=19006036

I use fossil on my computer for personal projects, scripts, and even my notes. Much prefer it to git.

> 2. A Few Reasons Why SQLite Does Not Use Git

It's fine if you don't want to use git, really.

But some of these objections don't make sense. Did you try "tig" and bare repos on a local machine/server?

It may make more sense once you realize Fossil development started in 2005. Quoting https://fossil-scm.org/home/doc/trunk/www/history.md :

> Beginning around 2005, the need for a better version control system for SQLite began to become evident. The SQLite architect looked around for a suitable replacement. Monotone, Git, and Mercurial were all considered. But at that time, none of these supported sync over ordinary HTTP, none could be run from an inexpensive shell account on a leased server (this was before the widespread availability of affordable virtual private servers), and none of them supported anything resembling the wiki and ticket features of CVSTrac that had been found to be so useful.

This is three years before GitHub was founded, and long before tig was released.

How should other people look at us? We always have to change these core things. From proprietary source control to CVS - that was actually a good idea because it was the open source standard. Then we all changed again to SVN for reasons I can't remember and then to GIT. And indeed it is about time to change again.

For the others who have to earn the money to support these follies, it is all the same. We could as well have sticked to CVS.

More on topic. Half of the complaints are data issues (I can not see things the way want to see them). That is easy to solve without killing GIT. And the argument that it is too complex, I see the contrary evolving where everybody is following the pattern set out by Github et al.

CVS tracked files. SVN tracks directories. That alone was a huge change in itself.

I'd like to see Visual Studio able to use Fossil for its source control management rather than only really supporting Git. I suppose Microsoft owning Github is a major factor there, but it would be nice if there was at least an extension to do it. There's apparently one for VS Code.

The VS Code one is very nice. It even emulates staging, which isn't a thing in Fossil.

I would love to use Fossil, but I'm afraid it doesn't have its Magit...

It's a shame they don't use a SQLite database for version control. I know it's probably the least efficient way to store code changes but it would bring a whole new level to bootstrapping processes. Each code change would be inserted into the db by the code produced by the prior change.

It would be exciting as it is stable.

Fossil does use SQLite as its storage engine.

See point 7 on the "about fossil" page:

https://fossil-scm.org/home/doc/trunk/www/index.wiki

You do realise that both Fossil and SQLite have the same creator?

> I know it's probably the least efficient way to store code changes

Not at all. Fossil's own repository (sqlite) database currently (as of this moment) has an overall compression ratio of 101:1, packing a total of 6.7GB of data into 66.5mb.

Reply on news.ycombinator.com