Stefan Beller writes:
>> At the implementation level, it should have a
>> hashtable (lazily populated) for all the objects in a single
>> $GIT_OBJECT_DIRECTORY, grafts/replace info, and a set of pointers to
>> other object-store instances that are its alternate object stores.
>
> So one repositor
On Tue, Jul 11, 2017 at 11:46 AM, Junio C Hamano wrote:
> Brandon Williams writes:
>
>>> the_repository -> the_object_store
>>> but the object store is a complex beast having different hash tables
>>> for the different alternates.
>>
>> After looking at the patch and some of the comments he
Brandon Williams writes:
>> the_repository -> the_object_store
>> but the object store is a complex beast having different hash tables
>> for the different alternates.
>
> After looking at the patch and some of the comments here I think that
> this is probably the best approach with a few t
On 07/10, Stefan Beller wrote:
> On Fri, Jul 7, 2017 at 9:50 AM, Junio C Hamano wrote:
> > Ben Peart writes:
> >
> >> For more API/state design purity, I wonder if there should be an
> >> object_store structure that is passed to each of the object store APIs
> >> instead of passing the repository
On Fri, Jul 7, 2017 at 9:50 AM, Junio C Hamano wrote:
> Ben Peart writes:
>
>> For more API/state design purity, I wonder if there should be an
>> object_store structure that is passed to each of the object store APIs
>> instead of passing the repository object. The repository object could
>> the
Ben Peart writes:
> For more API/state design purity, I wonder if there should be an
> object_store structure that is passed to each of the object store APIs
> instead of passing the repository object. The repository object could
> then contain an instance of the object_store structure.
>
> That
On 7/6/2017 10:33 PM, Junio C Hamano wrote:
Stefan Beller writes:
Subject: Re: [RFC/WIP PATCH] object store classification
I thought you are writing different object-store backends and
classifying them into many categories (e.g. local, networked,
telepathic, etc.)
It is a logical next
Stefan Beller writes:
> Subject: Re: [RFC/WIP PATCH] object store classification
I thought you are writing different object-store backends and
classifying them into many categories (e.g. local, networked,
telepathic, etc.)
It is a logical next step to put per-repository things i
This continues the efforts of bw/repo-object, making our code base
more object oriented by adding the object store to the the repository struct.
Long term goal of the series that would evolve from this discussion:
* Easier to implement submodule features as it can be in the same process.
Short te
9 matches
Mail list logo