On Fri, Jul 29, 2016 at 4:21 PM, Christian Couder <christian.cou...@gmail.com> wrote: >> I agree we should avoid this. There's a bunch of cache_name_pos() (and >> even read_cache()) in the libified apply.c, those will need to be >> converted to take struct index_state* directly (read_index_from or >> index_name_pos). > > There is a lot of other "libified" code that is calling these functions: > > $ git grep -l cache_name_pos -- '*.c' | grep -v builtin > apply.c > diff.c > dir.c > merge-recursive.c > pathspec.c > rerere.c > sha1_name.c > submodule.c > wt-status.c
Irrelevant? > $ git grep -l read_cache -- '*.c' | grep -v builtin | egrep -v '^t/' > apply.c > check-racy.c > diff.c > dir.c > merge-recursive.c > merge.c > read-cache.c > rerere.c > revision.c > sequencer.c > sha1_name.c > submodule.c > > and some of that code is perhaps directly and indirectly called by the > libified apply code. Yeah. If the libification movement is going strong, we can start converting and at some point should be able to define NO_THE_INDEX_COMPATIBILITY_MACROS globally (and avoid the_index along the way) Without that, there is a risk. I looked at 'nm apply.o | grep ' [Uu] '' and I don't see any external functions that would potentially access the index, except ll_merge. Again there's a good chance I may have missed something. > So it looks like it is a very big and different project to make the > current libified code be explicit about which index it is using. > And by the way perhaps this other project should just remove the > "the_index" global altogether. This is probably the way to go. But it's the boring sort of work that nobody wants to do :( -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
