Of course, we can’t leave out a mention of Fossil here — the SCM system built by and for SQLite.<p><a href="https://fossil-scm.org/" rel="nofollow">https://fossil-scm.org/</a>
And fossil itself is an SQLite database!
How much does it take advantage of being a DB underneath?
yeah fossil is great, but can fossil import the linux kernel (already working on the next post)
Still halfway through reading, but what you've made can unlock a lot of use cases.<p>> I tried SQLite first, but its extension API is limited and write performance with custom storage was painfully slow<p>For many use cases, write performance does not matter much. Other than the initial import, in many cases we don't change text that fast. But the simpler logistics of having a sqlite database, with the dual (git+SQL) access to text is huge.<p>That said, for the specific use case I have in mind, postgres is perfectly fine
SQLite is fine right up until you want concurrent writers. Once you need multiple users, cross-host access, or anything that looks like shared infra instead of a local cache, the file-locking model stops being cute and starts setting the rules for the whole design. For collaborative versioning, Postgres makes more sense.
For a distributed VCS, what would be the need for such things? Even if it were a really big project, how many writes could be going on that this becomes a bottleneck? I don't see it but maybe you have a situation in mind.
Also SQLite in WAL/WAL2 mode is definitely not amy slower for writing than Postgres either.
sounds great yes. maybe an SQLite version will come in the future
[dead]
Why a custom LLM prompt for what appears to be the default 'report' you'd want? Wouldn't the CLI just do this for a report command?<p>Is there an example of the tool enabling LLM 'discovering' something non-deterministic and surprising?
How well does this support random-access queries to the file names and content at a certain revision? Like:<p>- "Checking out" a specific branch (which can be reasonably slow)<p>- Query all files and folders in path `/src`<p>- Query all files and folders in path `/src/*` (and maybe with extra pattern matches)<p>- Be able to read contents of a file from a certain offset for a certain length<p>These are similar to file system queries to a working directory
This is incredibly neat and might actually become a part of my toolbox.
why do agents need to know these metas about git history to perform its coding functions though?<p>even humans don’t do this unless there’s a crazy bug causing them to search around every possible angles.<p>that said, this sound like a great and fun project to work on.
Wouldn't duckdb be better suited for this?
Forgive the stupid question. I just connected "csv as sql" to "git as sql" and duckdb comes to mind
I love it. I love having agents write SQL. It's very efficient use of context and it doesn't try to reinvent informal retrieval part of following the context.<p>Did you find you needed to give agents the schema produced by this or they just query it themselves from postgres?
so most analyses already have a CLI function you can just call with parameters. for those that don't, in my case, the agent just looked at the --help of the commands and was able to perform the queries.
Interesting... could be used to store multiple git repos and do a full text search across the multiple repos ?
[dead]