This is interesting. I wonder if he’s actually working on it:
Q: If you magically had enough extra time to do one additional thing at work that you’re not doing now, what would it be?
A: Oh, I’ve got a long list. But my #1 thing right now I think would be a new version control system which the working name is Fit, it’s a combination of Fossil with Git. Uses the Fossil user interface but it uses the low-level file format of Git. So that then you can work with Fossil’s interface but push and pull to legacy Git users. And I think that would be huge.
That would be really nice. I think there is definitely room for version control for people who are less in the programming realm or who work on personal projects that have a more creative art flavour (writers, desingers, etc). The user interface of Git is too frustrating for these types. Even as a mathematician and somewhat-programmer I dislike Git a lot. Rebase, blame, stash...ugghhh. Although Git is nice I liked Subversion better.
Have you used Mercurial? I found it a lot more user friendly, especially with TortoiseHg for Windows. Not sure if that’s still around as I don’t use Windows any more but even though there are many similarities, git always feels like it’s designed to solve problems I don’t want to use source control to solve.
TortoiseHg is still maintained and works both on windows (no direct experience) and linux.
The development happens on its mailing list, but there is also an Heptapod (a gitlab fork modified to also support mercurial) instance here: https://foss.heptapod.net/mercurial/tortoisehg
Interesting enough, almost all my work nowadays consists of interacion with git remotes. But my local clone has always been mercurial via hg-git.
Non-programmers aren't going to want any CLI version control, and git-cola plus meld is perfectly fine for simple use cases as long as nobody force pushes or uses a submodule or something like that.
Although usually what seems to happen is people only use one linear history and never branch anything. I'm not sure if that's because Git is hard, or just because nobody wants to learn about branches and stuff in any system if they don't have to.
In any case it works perfectly fine and is an amazing step up compared to no VCS.
> Uses the Fossil user interface but it uses the low-level file format of Git. So that then you can work with Fossil’s interface but push and pull to legacy Git users.
I'm surprised that's the #1 magic-wand project for anyone. I'm not trying to yuck his yum, but am just surprised.
But the larger elephant in the room for any such effort is that Fossil's mental model is, by choice, way different from git. If they just want a new ui that isn't as "git sux," surely a new cli to kid-gloves git would be less work than trying to reinvent a whole new version control system, and that goes 1000x for trying to maintain wire compat with every git server in the world
> I’m surprised that’s the #1 magic-wand project for anyone.
It seems like Dr. Hipp is frustrated that Fossil hasn’t had mainstream adoption, and that git has, he’s talked about it quite a bit in Fossil docs and here on HN. Given that SQLite is very stable and adoption is an absolutely runaway success, I’m not too surprised his wish list now turns to Fossil.
> Fossil’s mental model is, by choice, way different from git.
Is that accurate? It does come with a ton of extra features, but seems like the core version control model is quite similar conceptually, and differs more on implementation (SQLite backing instead of file system) and workflow dogma (Fossil’s moralizing of rebase and commit graph edits). The Fossil docs even start with “The feature sets of Fossil and Git overlap in many ways.” Fossil was released after but within a year of git being released, the timeline and docs and comments from the authors generally suggest it’s a reaction to git, taking the good parts and trying to, in the authors’ eyes, improve and fix their perceived problems with git.
I don't mean DAG versus "lolol," because I'm not saying Fossil isn't an SCM, I'm pointing out the design choices which presumably someone who wants to use Fossil buys into and thus would be a culture clash with trying to participate with the git upstream. I am cognizant this is quoting a bunch from the same page but pull-quotes the anti-git stance that makes me question whether this is a technical problem
We'll start with Fossil not tolerating `git rebase` or `git commit --amend`: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... and the number of repos I've seen where PRs don't land without someone chirping about "please rebase your branch"
and its related topic: "Fossil is not designed for drive-by contributions" and "Where Git encourages siloed development, Fossil fights against it.": https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... -- I would be really sad to have all my working changes auto-pushed by the tool, although the https://github.com/martinvonz/jj#readme is also in that spirit, where almost every operation is a `git add . && git commit -mwip`
Yeah I agree, this isn’t a technical problem. The stated goal is to build the Fossil interface using the git engine, so it’s not Fossil, it’s just an implementation of git that is compatible with Fossil’s workflow. It seems like the assumption there is maybe people want Fossil’s workflow but are stuck having to use git because it’s entrenched.
BTW, Fossil’s comparisons to git (especially rebase and rewriting) have always been hyperbolic. It’s improving slowly over the years, however the fundamental problem is still there: the Fossil team is presumptuously stating git’s intentions under Fossil’s overtly moral framework. Git devs have never stated any intention “to record what the development of a project should have looked like had there been no mistakes.” That’s the Fossil team framing things to sell the idea behind Fossil. Ironically, the Fossil team is attempting to rewrite the history of git development by using such language. I think the reason behind Fossil’s lack of adoption isn’t because git is entrenched, I suspect it’s because very few people care about having the ability to record in stone every single commit no matter how messy, most people enjoy having the ability to clean up after the fact. (Not to mention that the idea of capturing and preserving an exact “history” is misguided and fundamentally impossible; it’s already up to me what I put in a commit in the first place, and Fossil is providing dis-incentives to commit early and often, undermining the safety reasons to have version control in the first place.)
> Git devs have never stated any intention “to record what the development of a project should have looked like had there been no mistakes.”
Is that quote talking about the development of git, the VCS itself, or about what people use git for; are your "Git devs" the people who develop git, or those who use it to develop other software?
As I understand it, some git workflows (that is, workflows using git) are heavy into rewriting history and eliminating branches (or never starting them in the first place) and stuff, but the developers of git never foresaw or mandated that. So my own answer to my question above would be ~"The statement is about both: The developers of git never said that you must use git to straighten out and prettify the history "of a project." Am I reading you correctly in that this is what you too are saying?
Because if you are, then I agree: Sounds like Dr Hipp is exaggerating a little, trying to imply that one particular kind of workflow were (almost) mandatory in git. Creates a bit of a strawman, because that kind of workflow is easier to argue against than arguing against a product that allows that kind of workflow and other kinds.
I can’t speak for exactly what the Fossil team meant with that quote, but I guess I don’t think it matters, because the quote isn’t fully in good faith no matter how you take it. I mean it’s no worse than a TV commercial where they make problems look worse than they are to trash the competitor’s product, but it’s no better either. You read my intention correctly, I mean that the developers of git are not enforcing a workflow wrt history (unlike the developers of Fossil). The language on Fossil’s git comparison page use to be worse, it use to say “Rebase is a Lie”, and it used to talk about how people who rewrite history are “fabricating” and “lying”. I actually had a direct conversation with Dr. Hipp here on HN where he agree to soften the language a bit, and he did, which I respect… he is listening. He does, however, believe strongly in the idea that commit history should not be allowed to be ‘rewritten’, so much so that he considers rewriting to be akin to criminal activity. While I don’t agree with that, I have no qualms whatsoever about a VCS that preserves history. It might actually be a really good idea, as long as it’s practical and can be managed and serves the purposes of version control. My only beef is the hyperbolic comparisons to git, the claims that presume to state git’s intent.
The counterpoint is that Git's enables multiple workflows, especially branching and merging, rather than just trunk-based development. Not to say you can't do the latter in Git, but people might struggle to adapt.
I think trunk-based, warts and all, is probably the best method for a team that isn't extremely async. Which, I think, makes it useful for a large number of projects.
> We'll start with Fossil not tolerating `git rebase` or `git commit --amend`: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... and the number of repos I've seen where PRs don't land without someone chirping about "please rebase your branch"
How's that "feature" of fossil ? You can just decide to not allow it in Git as you see fit, and it is something that is useful once you know how to.
This whole set basically sounds like "Git allows you to do all that but fossil forces you to work its way". Which is fine but you could... just decide to do it in git.
It does show that fossil is trying different approach, it doesn't want to be really distribute as much as just "synced"
Git’s UI is difficult, yes, but I’m sure far more people are familiar with it at this point than Fossil. It would be far more inefficient for me to learn Fossil’s commands for what I need Git to do than just continuing to use Git, at least in the short term (and with no guarantees it’ll improve in the long term). If anything, a tool which goes the other way around - allows me to interact with Fossil using familiar Git commands - seems more useful to me.
This is the case for a lot of tools. There was a time that for a majority of people on the planet, handwriting a letter would be faster than typing it up too.
the main reason i'm not all-in on Fossil is because you cannot squash commits; my WIP branch history is very messy, e.g. "looks to be working", "refactor", "typo", "optimize", "undo checkpoint". i don't need any of that junk on the `main` branch once the feature branch is merged.
it's really too bad, everything else in Fossil looks very compelling.
It sounds like you have experience with Fossil; is it that "YOU can hide those commits" meaning you can omit them if you don't get value from them, or is it that "you can HIDE those commits" meaning "UPDATE commit SET hidden = true" so everyone in this "git push --mirror" world also benefits from you declaring the commits to be "of little value"?
First, it's discouraged in Fossil, because the right way to do it is to just hide stuff in your "select" view(generally the dashboard in the web UI), so it only shows the stuff you want anyway, i.e. everything is visible, but you select your view to only show the stuff you care about at the time. I.e. don't change the back-end data, change the query you use to view it.
If you are bound and determined to hide it by default, then, it's just a flag attached to a commit or a branch(by default in the CLI, it can only apply to branches):
fossil amend --hide <branchname>
If you want to hide individual commits, you have to work a touch harder:
Yes, the ability hasn't made it to the CLI (yet?), but the web GUI does honour the hidden flag.
If you run `fossil timeline --sql`, you can then change the sql to skip the hidden flag, though I'm not sure where in the commit that is, one would have to do some digging.
Fossil's perspective is deleting/altering and tampering with history is a terrible idea. Some code shops have legal or policy mandates that disallow them from altering history anyway. My employer is such a place. Yes we have a few 'typo' commits that get through, but whatever. In practice it's a non-issue, since Fossil is just a sqlite DB, you can do what amounts to a select * from commits where 'typo' not in commit_msg, and never see them, without doing anything in the second paragraph, which shows you how to do all of this if you are bound and determined.
Well, since Fossil stores its stuff in an SQLite database, I'd assume that if you know SQL and the password to your Fossil repo, you can delete and alter history...?
After all, SQL consists not only of the SELECT command; it has DELETE and INSERT too.
I think it is just being practical. Much to my chagrin, git has consumed the world. The Fossil tooling offers a reasonably slick (well, not the CSS) out of the box experience which would be nice to have elsewhere.
It's been so long since Git has received a user interface update, that's why GitHub, GitLab and BitBucket had good ideas and made it big. Now I wonder if programmers will ditch Git and go to Fit.
It's getting small usability updates from time to time.
Also GH/GL is popular because of everything else they do (issues, page rendering, now CI/CD) not because git CLI is too hard.
Improvements are welcome of course but the moment newbie hits merge conflict no amount of CLI niceness can get around them not knowing what to do with it and that's true regardless of DVCS. For "non-programmers" no CLI is good enough anyway.
Git is primarily a file format. There's also a canonical set of low-level command-line utilities. But you can create whatever interface you want. Most programmers and GUIs happen to use the canonical command-line tools, but that's hardly necessary. Fit would keep the necessary part of Git (the file format), and provide a different human interface.
I'd imagine legacy users would just see a unconnected branch with a bunch of textfiles. fit-tickets for tickets, fit-wiki for wiki, fit-docs for docs etc.
I’m going to write my own mail server. I was making notes on that even as we were setting up this call. That’s a big problem, and that’s at least as difficult if not more difficult than writing a database engine, but I don’t want to be beholden to Gmail. I don’t want them controlling my destiny. I don’t want them controlling the record of all of my conversations. I want to control that myself, and so I’m going to go through a lot of pain and a lot of work and a lot of effort to come up with some solution that I can control myself. I can go out and lease a virtual machine out there in the cloud and run it myself and not depend on a third party to control my email.
Some kind of "all in one" where you have SQLite file with config (aliases/accounts etc) + maybe SQLite file per account for storage + some sane SMTP/IMAP config with DKIM and all the other crap spammers implement anyway but servers will spam you for if yu don't have it would be useful.
I've recently did a small server for private use (after google yeeted the free tier) and let's say it does require a bit of mail knowledge to set it up right.
That being said there is probably some container doing it, surely "easy mail selfhosting" isn't a new problem
Yeah, but aren't there lots of open-source e-mail systems already that he could just set up his own instance of and administer for himself -- thus achieving both the "control" and the "privacy" goal -- in stead of writing a new one?
I've been trying to use SQLite3 in an embedded (ESP32 -- dual core 240MHz w/ qspi NOR flash) project and the performance has been surprisingly bad. Seems like the minimum amount of time to make a query (even for example, selecting from a table that does not exist, takes a minimum of 5ms). For a simple table with 10 short columns I'm getting 10s of milliseconds per record to SELECT. I can parse whole JSON files with the same data to RAM faster then I can query SQLite which seems wrong. SQLite is performing ~10x worse than I'd expected it would.
Anyone had experience running SQLite on low-power embedded platforms? Is this expected performance?
In the embedded world the specifics often outweigh the general. Specifics like - what storage are you using? What clock does it run at? What page size are you using (you'd want to pass this to sqlite for best results)? What locks are you using? Is there a 1mS undocumented sleep on startup to allow some peripheral to stabilise that accidentally got pulled in to the main code path (has happened to me - the initialize function didn't set the initialized flag)?
I'd expect closer to 5uS than 5mS, but I'm not that familiar with the ESP32 devices
Is your 5us number from experience? Have you run SQLite on embedded before? Just hoping to hear some real world performance numbers for any hardware remotely similar!
I have run sqlite on a flash chip before (no filesystem, I suppose sqlite _was_ the filesystem) but I never took benchmarks. It was a 200MHz processor as well and it was basically fast enough out of the box that I never spent time on it. For 5uS response you have something like a thousand cycles to work with so any issue is likely storage related. I'd expect writes to be a bottleneck for example
Could you share some source code around your implementation? Selecting from a non-existing table should be a very quick operation. I suspect you might be doing something like creating a new connection per command if you are seeing this behavior.
> There aren't connections in SQLite like there are for network-connected DBs (eg MySQL)
The handle named `db` in your example is as expensive to create as a connection in the relative sense and should be optimized the same way in your application. It may be less expensive than a network database connection, but its still very expensive relative to any subsequent queries. The database file is opened, its first page is read, its schema is parsed from text (!), some memory is pre-allocated and so on every time you make that call.
The sqlite3_exec call invokes the parser and query optimizer every time it is called. A better benchmark would be to compile a valid statement (sqlite3_prepare). The unit under test should just be sqlite_bind() for relevant parameters followed by sqlite_step(), and maybe (but not necessarily) sqlite_reset().
If you have the RAM to load up a toy dataset, what happens if you utilize a :memory: database instead of disk? If the performance is the same, you know the problem exists outside of the storage.
Yeah seems like it would _have_ to be storage related but my profiling tools are limited. I've run Doom on this same processor/flash combo and loading assets from the WAD files is on the order of 1ms and I can run Doom smoothly at 70fps. Not very scientific but that's part of the reason I was surprised by how slow SQLite is running.
I wonder if it could be doing multiple small writes on every operation -- I could definitely imagine small writes getting very costly, especially with wear-leveled file systems that might be moving around pages on even small writes.
This depends entirely on how naive the sqlite implementation is - without exact implementation details and register values for the QSPI peripheral, it's hard to remote diagnose something like that.
Have you used a digital logic analyzer to figure out how long reading the page takes, how many pages SQLite reads for that query, and how much work SQLite has to do before it can fetch the next page? I haven't seen any ESP32 SQLite ports that can eagerly fetch pages, even though it's relatively simple to do with DMA (but would require some significant changes to SQLite because it's designed to be ignorant of OS preemption which is not the case in most RTOSes).
There are great bits of discussion about SQLite being maintained and enhanced by a very small team - three people.
While I very much appreciate the safety of being a very small cog in a larger machine, I also wonder how my career might be more enjoyable and satisfying if I had chosen to limit my options to small teams where every single person on the team had a critical impact on the success of a project.
There are organizations, even large ones, that prefer to work this week. Trying to set the maximum number of team members to 6 people including a PM and a designer. As you move through your career I highly recommend adding a question during the interview process to address this. It really does make a big difference on your quality of life, and you'll make some great friends along the way.
That kinda entirely depends with what people you're stuck with. In 6-10 person team you can just avoid working with that one colleague you just can't gel with (even if they might be perfectly fine from competency standpoint).
I think medium-sized projects (say a team of max 10, or maybe 2 smaller ones) seems to be the most fun ones. You have enough manpower to do some bigger reorganizing if required but it isn't as big that rewrite of any part is years-long saga.
Is there a succession plan in place given the bus factor [1] with such a small team? Is anyone else concerned about maintenance if either a normal everyday medical issue came up or in the worst case something unimaginable?
From my perspective, SQLite is stable enough to be considered "done". For our product, we could go back to builds from 2020 and none of our customers would be able to detect a difference.
SQLite is not something we wire up and expose bare-ass to the public internet. We don't worry about 0-day security issues in this context. It's more like a wrapper our product uses for structured disk access. Anything that would warrant urgent patching is in .NET vendor or in-house software piles.
If something horrible happened and the entire SQLite dev team was wiped off the face of the planet, I'd make a note to look at alternatives by ~2025.
Yes, Dr. Hipp mentioned it once that there is a foundation in place to take care of things and increase the bus factor. I think that was one of the conditions before Nokia signed their agreement to license SQLite for Symbian.
Q: If you magically had enough extra time to do one additional thing at work that you’re not doing now, what would it be?
A: Oh, I’ve got a long list. But my #1 thing right now I think would be a new version control system which the working name is Fit, it’s a combination of Fossil with Git. Uses the Fossil user interface but it uses the low-level file format of Git. So that then you can work with Fossil’s interface but push and pull to legacy Git users. And I think that would be huge.