Re: [RFC/WIP] Pluggable reference backends

[Jeff King <peff@peff.net>]

On Mon, Mar 10, 2014 at 10:46:01AM -0700, Junio C Hamano wrote:

> >> No to SQLLite in git-core. Using it from JGit requires building
> >> SQLLite and a JNI wrapper, which makes JGit significantly less
> >> portable. I know SQLLite is pretty amazing, but implementing
> >> compatibility with it from JGit will be a big nightmare for us.
> >
> > That seems like a poor reason not to implement a pluggable feature for
> > git-core. If we implement it, then a site using only git-core can take
> > advantage of it. Sites with JGit cannot, and would use a different
> > pluggable storage mechanism that's supported by both. But if we don't
> > implement, it hurts people using only git-core, and it does not help
> > sites using JGit at all.
> 
> We would need to eventually have at least one backend that we know
> will play well with different Git implementations that matter
> (namely, git-core, Jgit and libgit2) before the feature can be
> widely adopted.

I assumed that the current refs/ and logs/ code, massaged into pluggable
backend form, would be the first such. And I wouldn't be surprised to
see some iteration on that once it is easier to move from scheme to
scheme (e.g., to use some encoding of the names on the filesystem to
avoid D/F conflicts, and thus allow reflogs for deleted refs).

> The first backend that is used while the plugging-interface is in
> development can be anything and does not have to be one that
> eventual ubiquitous one, however; as long as it is something that we
> do not mind carrying it forever, along with that final reference
> backend.  I take the objection from Shawn only as against making the
> sqlite that final one.

Sure, I'd agree with that. I'd think something like an sqlite interface
would be mainly of interest to people running busy servers. I don't know
that it would make a good default.

-Peff