git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC/WIP] Pluggable reference backends

From
David Kastrup <dak@gnu.org>
Date
Mar 10, 2014, 16:14 UTC
Message-ID
<87k3c2820l.fsf@fencepost.gnu.org>
In-Reply-To
<20140310155230.GA29801@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 16 quoted lines
> 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
Previous: Jeff KingNext: David Lang
Message 6 of 17 in “[RFC/WIP] Pluggable reference backends”
  1. Michael HaggertyMar 10, 2014
  2. Johan HerlandMar 10, 2014
  3. Shawn PearceMar 10, 2014
  4. Max HornMar 10, 2014
  5. Jeff KingMar 10, 2014
  6. David KastrupMar 10, 2014
  7. David LangMar 10, 2014
  8. Jeff KingMar 10, 2014
  9. David KastrupMar 10, 2014
  10. Junio C HamanoMar 10, 2014
  11. Jeff KingMar 10, 2014
  12. Michael HaggertyMar 10, 2014
  13. Shawn PearceMar 11, 2014
  14. egit vs. git behaviour (was: [RFC/WIP] Pluggable reference backends)Andreas Krey, Mar 12, 2014
  15. Shawn PearceMar 12, 2014
  16. Karsten BleesMar 11, 2014
  17. Michael HaggertyMar 12, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.