On 05/05, Junio C Hamano wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> 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