Re: [PATCH v2 4/4] bundle v3: the beginning

From: Duy Nguyen <pclouds@gmail.com>
Date: Jun 1, 2016, 14:00 UTC
Message-ID: <CACsJy8DB_17DZ7REBzicyA_GZCnvNkoYEzftjfyM72QVmEb_Vg@mail.gmail.com>
In-Reply-To: <CAP8UFD3jPQFk2deSk5JXC3PTz5yWcvXJ4=Qjam5Qw6P9SrLzFQ@mail.gmail.com>

On Tue, May 31, 2016 at 8:18 PM, Christian Couder <christian.couder@gmail.com> wrote:

Show 15 quoted lines

>>> [3] http://thread.gmane.org/gmane.comp.version-control.git/202902/focus=203020
>>
>> This points to  https://github.com/peff/git/commits/jk/external-odb
>> which is dead. Jeff, do you still have it somewhere, or is it not
>> worth looking at anymore?
>
> I have rebased, fixed and improved it a bit. I added write support for
> blobs. But the result is not very clean right now.
> I was going to send a RFC patch series after cleaning the result, but
> as you ask, here are some links to some branches:
>
> - https://github.com/chriscool/git/commits/gl-external-odb3 (the
> updated patches from Peff, plus 2 small patches from me)
> - https://github.com/chriscool/git/commits/gl-external-odb7 (the same
> as above, plus a number of WIP patches to add blob write support)

Thanks. I had a super quick look. It would be nice if you could give a high level overview on this (if you're going to spend a lot more time on it).

One random thought, maybe it's better to have a daemon for external odb right from the start (one for all odbs, or one per odb, I don't know). It could do fancy stuff like object caching if necessary, and it can avoid high cost handshake (e.g. via tls) every time a git process runs and gets one object. Reducing process spawn would definitely receive a big cheer from Windows crowd.

Any thought on object streaming support? It could be a big deal (might affect some design decisions). I would also think about how pack v4 fits in this (e.g. how a tree walker can still walk fast, a big promise of pack v4; I suppose if you still maintain "pack" concept over external odb then it might work). Not that it really matters. Pack v4 is the future, but the future can never be "today" :)

-- 
Duy