Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-08 Thread Thomas Rast
Junio C Hamano gits...@pobox.com writes: Thomas Rast tr...@student.ethz.ch 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

Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-08 Thread Nguyen Thai Ngoc Duy
On Wed, Aug 8, 2012 at 5:31 AM, Thomas Rast tr...@student.ethz.ch 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

Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-08 Thread Nguyen Thai Ngoc Duy
On Wed, Aug 8, 2012 at 8:38 AM, Junio C Hamano gits...@pobox.com 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

Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-08 Thread Junio C Hamano
Nguyen Thai Ngoc Duy pclo...@gmail.com 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

Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-08 Thread Junio C Hamano
Thomas Rast tr...@inf.ethz.ch writes: Junio C Hamano gits...@pobox.com writes: Thomas Rast tr...@student.ethz.ch 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

Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-08 Thread Nguyen Thai Ngoc Duy
On Wed, Aug 8, 2012 at 11:31 PM, Junio C Hamano gits...@pobox.com 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.

Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-07 Thread Junio C Hamano
Thomas Rast tr...@student.ethz.ch 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

Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-07 Thread Thomas Rast
Junio C Hamano gits...@pobox.com 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

Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-07 Thread Junio C Hamano
Nguyen Thai Ngoc Duy pclo...@gmail.com 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

Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-07 Thread Nguyen Thai Ngoc Duy
On Tue, Aug 7, 2012 at 12:46 AM, Junio C Hamano gits...@pobox.com 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).

Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-06 Thread Nguyễn Thái Ngọc Duy
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

Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-06 Thread Junio C Hamano
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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

Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-06 Thread Thomas Gummerer
On 08/06, Junio C Hamano wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com 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

Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-06 Thread Junio C Hamano
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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

[PATCH/RFC v2 0/16] Introduce index file format version 5

2012-08-05 Thread Thomas Gummerer
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