Relational database backend for mercurial or git

What I like about fossil is that it uses plain old sqlite to store changesets, files, etc. I can use its command line tool to query the repository, but if I want somet开发者_Go百科hing not supported by it, I can fallback to writing an sql query.

Mercurial and git are more mature, they have more libraries, more momentum, but they use their own repository format. I wonder if it's possible to have sqlite as their repository backend. (I know there are tools to query a mercurial or git repo directly, but sql seems easier.)

As Jefromi writes, Mercurial is also using a custom format to achive high compression and fast access to any revision. This is the revlog format which is an append-only data structure that takes advantage of the immutability of changesets in Mercurial.

However, it is of course possible to replace this storage format with another if you like. Google did this when they put Mercurial on Bigtable for code.google.com. One funny consequence of them using their own backend format is that you don't see any revision numbers in their web interface. In normal Mercurial, the revision numbers (the local-only integer you can use instead of the full changeset hash) are the index of the changesets in the revlog. When changesets are not stored in revlogs, there is no natural index and therefore Google shows you no revision numbers.

With git, the repository format is a pretty fundamental part of the way everything works. You'd have to do a lot of work to change that.

I haven't read any of mercurial's source, but I imagine the situation isn't much different.

As I suggested in my comment, I'm not really sure why you'd want to do this. For git to still be able to have all of its advantages, you'd have to store git objects in your sqlite database. You'd still need all of the low-level git tools to access and manipulate them - you're not going to be just looking up blobs and trees by their SHA1s and doing all the rest of the work yourself. (And even if for some reason you wanted to, you could do that just as easily by looking in the git objects directory.)

My suggestion would be that, if you find that there are operations you want to perform in git that are unsupported, you familiarize yourself with some of the plumbing commands and figure out how to write them as scripts. Git really does expose pretty much the lowest level of operations you could want.

P.S. If you should find a specific unsupported operation you want to do, and are having trouble finding the plumbing you need to perform it, or with the scripting necessary to implement it, post a question here! No reason to get stuck just because you can't use sql.

It's possible with libgit2 backends : https://github.com/libgit2/libgit2-backends/blob/master/sqlite/sqlite.c

I haven't done any measurement, but performance should suffer a bit. However, it's also more convenient (single file for the entire repo history, classic SQL query language..etc..)

Speaking for Git, you cannot use different backend with the official binaries. However, the libgit2 project allows you to use different backends to store the database. However, you'll have to build all the binaries you wish to use for committing, merging, pushing, pulling, rebasing, etc. Also, you won't be able to modify your repository with the official binaries. You'll have to push it to a standard repo first.