Re: [PATCH 0/5] Start of a journey: drop NO_THE_INDEX_COMPATIBILITY_MACROS

[Brandon Williams <bmwill@google.com>]

On 05/05, Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
> 
> > That is, one way to do what this series attempts would be the
> > following:
> >
> >  1. rename variables that shadow the_index.
> 
> No question about this one.  It is a good thing to do.
> 
> >  2. add coccinelle patches (or one coccinelle patch) to
> >     contrib/coccinelle implementing *_cache -> *_index migration.
> >     Is there a way to do this without making it fail "make coccicheck"?
> 
> Quite honestly, I do not see much value in this, but take it merely
> as my knee-jerk reaction.  The only scenario I can think of in which
> dropping *_cache() macros is an improvement as the end result is
> when our goal is to completely drop the singleton index_state
> instance, aka "the_index".  I actually think that it may be a
> worthwhile goal to eradicate "the_index".
> 
> I wonder if somebody can take a small example codepath and make it
> not to rely on the existence of "the_index" from start to end?  Have
> an instance of index_state on the stack of cmd_foo(), have it call
> read_index() into it where it currently calls read_cache(), update
> the support functions it calls so that it can pass the pointer to
> its index_info throughout the callchain, and see how involved the
> necessary changes of all of the above are.  Start from something
> simple and small, e.g. "ls-files".  The infrastructure code updated
> for such an experiment may be NO_THE_INDEX_COMPATIBILITY_MACROS
> clean.

I've mentioned elsewhere but I've been working on this for 'ls-files'.
There's quite a few "gotchas" but its given me a good idea of which
sections of code need to be converted to taking in a
'struct index_state'.  I'll send some of this conversion out later today
as a RFC and see what people think about it and if its worth while to
continue.

-- 
Brandon Williams