On Tue, May 29, 2012 at 8:29 PM, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote: > I envision an index API that more strictly controls access to the index. > Right now the API consists largely of read_index, write_index and the > flat the_index->cache array of entries. Eventually it will have to be a > family of calls that support the v5 format, and boil down to suitable > wrappers for older ones. For example (just tossing up ideas): > > index_open(struct index_state *index, int fd): > initialization, checking, leaves the "real" data fields empty > > index_load_filtered(..., const char **pathspec): > load everything needed to satisfy queries filtered by 'pathspec' > > index_for_each_entry(..., void (*callback)(struct cache_entry *ent)): > like the current hand-rolled looping > > index_for_each_entry_filtered(..., void (*callback)(struct cache_entry *ent), char **pathspec): > ditto but for a pathspec lookup > > etc. I'm towards readdir interface with filter flags (e.g. staged entries only, unmerged only, all...) for serial access and something like stat() for one-file check. That may be enough for ls-files conversion. With readdir-like interface where entries are sorted, I can help add pathspec support to tree_entry_interesting(). This function can be used by new ls-files to filter pathspec instead of the list-based pathspec_matches(). One thing to consider is, will this new API work with old versions too (i.e. can conversion be hidden behind the scene without significant performance loss)? If it does, great we only have to maintain one API, the future is bright. Otherwise, I don't know.. > Actually converting the rest of the git code base to such an API is too > big an undertaking for the summer, so please don't stray on that path. Agreed. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html