On Wed, Aug 8, 2012 at 11:31 PM, Junio C Hamano wrote:
> The current code that access nth entry from the index->cache[nth]
> would need to be updated to use an accessor function, whether the
> "nth" comes from index_name_pos() or from the for-loop that iterates
> over the entire index. For the la
Thomas Rast writes:
> Junio C Hamano writes:
>
>> Thomas Rast writes:
>>
>>> I like the general idea, too, but I think there is a long way ahead, and
>>> we shouldn't hold up v5 on this.
>>
>> We shouldn't rush, only to keep some deadline, and regret it later
>> that we butchered the index form
Nguyen Thai Ngoc Duy writes:
> OK how about this. The general idea is preserve/extend current flat
> index API and add a new (tree-based) one. Index users can use either.
> They can even mix them up (which they do because we can't just flip
> the API in one day for about 200 source files).
>
> Th
On Wed, Aug 8, 2012 at 8:38 AM, Junio C Hamano wrote:
> If the workload we _care_ about is served better by using an API
> that works over an in-core tree-shaped index data structure, I do
> not think it is unreasonable to read the v2 on-disk format and
> represent it as a tree-shaped index while
On Wed, Aug 8, 2012 at 5:31 AM, Thomas Rast wrote:
> Thomas and me -- it was mostly my bad idea -- spent some time going
> through all the loops that iterate over the index. You can get some
> taste of it with 'git grep ce_stage', mostly because many of them either
> skip unmerged entries or spec
Junio C Hamano writes:
> Thomas Rast writes:
>
>> I like the general idea, too, but I think there is a long way ahead, and
>> we shouldn't hold up v5 on this.
>
> We shouldn't rush, only to keep some deadline, and regret it later
> that we butchered the index format without thinking things throu
Nguyen Thai Ngoc Duy writes:
> add_to_index and remove_index_entry_at seem good places for the cut.
> But do we need to redefine the location?
That is one of the things we need to think about carefully. Of
course, if add_to_index() just takes a pathname out of the ce the
caller wants to add, yo
Junio C Hamano writes:
>> Then of course you need to split the second patch into several logical
>> patches again. We can drop _v5 suffix in read-cache-v5.c (I haven't
>> done that). When we add partial read/write for v5, we can add more
>> func pointers to index_ops and implement them in v2 (pro
Thomas Rast writes:
> I like the general idea, too, but I think there is a long way ahead, and
> we shouldn't hold up v5 on this.
We shouldn't rush, only to keep some deadline, and regret it later
that we butchered the index format without thinking things through.
When this was added to the GSoC
On Tue, Aug 7, 2012 at 12:46 AM, Junio C Hamano wrote:
> The index_ops abstraction is a right way to go, and I like it, but I
> think the split illustrated in this patch might turn out to be at
> wrong levels (and it is OK, as I understand this is a illustration
> of concept patch).
>
> For exampl
Nguyễn Thái Ngọc Duy writes:
> These mails are about cosmetics only. But I think it helps maintenance
> in long term. I notice in your series we have many functions with _v2
> and _v5 mixed together. Worse, some functions that are _v2 only are
> not suffixed with _v2. I still think separating v2/
On 08/06, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> > These mails are about cosmetics only. But I think it helps maintenance
> > in long term. I notice in your series we have many functions with _v2
> > and _v5 mixed together. Worse, some functions that are _v2 only are
> > not su
Nguyễn Thái Ngọc Duy writes:
> These mails are about cosmetics only. But I think it helps maintenance
> in long term. I notice in your series we have many functions with _v2
> and _v5 mixed together. Worse, some functions that are _v2 only are
> not suffixed with _v2. I still think separating v2
These mails are about cosmetics only. But I think it helps maintenance
in long term. I notice in your series we have many functions with _v2
and _v5 mixed together. Worse, some functions that are _v2 only are
not suffixed with _v2. I still think separating v2/v5 changes is a
good idea. So I played
Fist again apologies for those who were not credited in the first
version of this series.
The first version of the series was here: $gmane/202752.
Changes since the last version:
This series now applies to the latest master.
[PATCH/RFC v2 01/16] Modify cache_header to prepare for other index fo
15 matches
Mail list logo
