On Tue, Aug 5, 2014 at 2:56 PM, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: > Personally (a user of, not a maintainer of, git) I really want some > alternative backends. In particular I'm after something like Fossil's > use of SQLite3; I want a SQLite3 backend for several reasons, not the > least of which is the power of SQL for looking at history. > > I'm not sure that I necessarily want a daemon/background process. I > get the appeal (add inotify and bingo, very fast git status, always), > but it seems likely to add obnoxious failure modes. > > As to a SQLite3-type backend, I am of two minds: either add it as a > bolt-on to the builtin backend, or add it as a first-class backend > that replaces the builtin one. The former is nice because the SQLite3 > DB becomes more of a cache/index and query engine than a store, and > can be used without migrating any repos, but the latter is also nice > because SQLite3 provides strong ACID transactional semantics on local > filesystems. This will allow you to do either or both, depending on what you want. I am adding one new first-class backend to talk to a separate daemon : refs-be-db.c which then talks to a separate daemon refsd-tdb.c refsd-tdb.c is 7 RPCs and ~500 lines of code for a naive implementation for a standalone separate daemon implementation. If you rather want want a new first-class backend builtin to git itself instead of as a separate daemon, then that will be possible too. It just means that you will have to base the work on refs-be-db.c which is a much larger and complex code base than refsd-tdb.c. But yeah, once this work is finished, you will be able to build new first-class ref backends if you so wish. Please see refs-be-db.c that is the file and the methods you will need to implement in order to have a first-class SQL* backend. regards ronnie sahlberg -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html