On 03/10/2014 04:52 PM, Jeff King wrote: > On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote: > >>> * Store references in a SQLite database, to get correct transaction >>> handling. >> >> 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.
I think it's important to distinguish between two types of backend: * Exotic backends, optimized for servers, or embedded systems, or other controlled environments where the person deploying Git can decide about the whole technology stack. Here I say let a thousand flowers bloom. If user A wants to try an Oracle backend and only uses JGit, there's no need for him to implement the equivalent backend for git-core or libgit2. * Mainstream backends, intended for use by end-users on their workstations and notebooks. Such backends will be pretty worthless if they are not supported more or less universally, because one user will want to use the command line and Eclipse, another Visual Studio and TortoiseGit, a third will use GitHub for Mac plus a bunch of shell scripts written by his IT department. A backend that is not supported by the big three Git implementations (git-core, libgit2, and JGit) will probably be rejected by users. Realistically there will be at most a couple of mainstream backends--in fact probably usually a single established one and occasionally a single next-generation one waiting for people to migrate slowly to it. For mainstream backends I think it is important for the implementations to plan and coordinate ahead of time to make sure everybody's concerns are addressed. It sounds to me like Shawn is saying "please don't make a SQLite-based backend the new default git-core backend" and Peff is saying "there is no reason that a Git hosting service shouldn't experiment with a SQLite-based backend". I see no contradiction there [1]. Also, please remember that I'm not advocating a SQLite backend or any other at this time. I'm only refactoring code to open the way for *future* flamefests :-) Michael [1] There might of course be a technical argument about whether a SQLite-based backend would be SO AWESOME for end-users that switching to it would be worth the extra inconvenience for the JGit folks. Personally I'm skeptical. -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
