Re: [PATCH 05/22] read-cache: add index reading api
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 8, 2013, 16:36 UTC
- Message-ID
- <7va9lx100l.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <1373184720-29767-6-git-send-email-t.gummerer@gmail.com>
Thomas Gummerer <t.gummerer@gmail.com> writes:
Show 28 quoted lines
> Add an api for access to the index file. Currently there is only a very
> basic api for accessing the index file, which only allows a full read of
> the index, and lets the users of the data filter it. The new index api
> gives the users the possibility to use only part of the index and
> provides functions for iterating over and accessing cache entries.
>
> This simplifies future improvements to the in-memory format, as changes
> will be concentrated on one file, instead of the whole git source code.
>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
> cache.h | 57 +++++++++++++++++++++++++++++-
> read-cache-v2.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++--
> read-cache.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++----
> read-cache.h | 12 ++++++-
> 4 files changed, 263 insertions(+), 10 deletions(-)
>
> diff --git a/cache.h b/cache.h
> index 5082b34..d38dfbd 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -127,7 +127,8 @@ struct cache_entry {
> unsigned int ce_flags;
> unsigned int ce_namelen;
> unsigned char sha1[20];
> - struct cache_entry *next;
> + struct cache_entry *next; /* used by name_hash */
> + struct cache_entry *next_ce; /* used to keep a list of cache entries */The reader often needs to rewind the read-pointer partially while walking the index (e.g. next_cache_entry() in unpack-trees.c and how the o->cache_bottom position is used throughout the subsystem). I am not sure if this singly-linked list is a good way to go.
Show 8 quoted lines
> +/* > + * Options by which the index should be filtered when read partially. > + * > + * pathspec: The pathspec which the index entries have to match > + * seen: Used to return the seen parameter from match_pathspec() > + * max_prefix, max_prefix_len: These variables are set to the longest > + * common prefix, the length of the longest common prefix of the > + * given pathspec
These probably should use "struct pathspec" abstration, not just the "array of raw strings", no?