Re: Our merge bases sometimes suck

From: Jakub Narębski <jnareb@gmail.com>
Date: Jun 23, 2014, 11:43 UTC
Message-ID: <53A812D0.1080402@gmail.com>
In-Reply-To: <CAK3OfOjfyrsN47Ho0MFh4VZUg6YMjjwPOa16iuw3xtqyhz16hg@mail.gmail.com>

W dniu 2014-06-20 23:17, Nico Williams pisze:

Show 10 quoted lines

> On Fri, Jun 20, 2014 at 1:53 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>> [...]
>>
>> Hmph, but that obviously will become very expensive to compute as
>> project grows.
>
> That's the main reason to like Fossil's approach (namely, the use of
> SQL, specifically SQLite3): you can write declarative queries and let
> the query planner optimize.

I do wonder if using *generic* RDBMS / key-value store would really make Git faster than current filesystem-like approach.

BTW. perhaps caching generation numbers would help here; the idea of adding performance-helper generation number header to commit object was rejected.

> (That's also about the only thing I like about Fossil: the use of
> SQL/SQLite3, and all that that implies.  Fossil is otherwise an
> anti-git, and that makes it useless for me.)

There are Bazaar and Veracity that are supposed to have pluggable backends...

-- 
Jakub Narębski