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 -- 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