Jeff King <peff@xxxxxxxx> writes: > 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. Of course, the basic premise for this feature is "let's assume that our file and/or operating system suck at providing file system functionality at file name granularity". There have been two historically approaches to that problem that are not independent: a) use Linux b) kick Linus. Option b) has been fairly successful over quite a bit of time, but at the current point of time, it has become harder to aim that kick on a single person and/or where it counts. The database approach is an alternative approach based on kicking an alternate set of people, namely database rather than operating system providers, based on the assumption that the former have softer behinds (the backend-based approach) making them more sensitive to kicking. So the database approach is most promising on the "what are we going to do if our operating system vendor won't bother with sensible file system performance" angle. Which isn't doing total system architecture a favor. Personally, I have little sympathy for helping subpar systems, keeping them on life support while they are in turn trying to squish the better systems. But then it is not me doing the actual work, so this is no more than an idle reflection. -- David Kastrup -- 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