Re: [PATCH v8 32/41] environment: add set_index_file()

From: Duy Nguyen <pclouds@gmail.com>
Date: Jul 29, 2016, 15:34 UTC
Message-ID: <CACsJy8CT2r1MKE_bQotPzKEWi10QB81sNn6w7H23GxRkEYRFfg@mail.gmail.com>
In-Reply-To: <CAP8UFD1SSjSGV+1e+zP4s=p+ohgSz6mct3EhPXqbde_y48ST7g@mail.gmail.com>

On Fri, Jul 29, 2016 at 4:21 PM, Christian Couder <christian.couder@gmail.com> wrote:

Show 17 quoted lines

>> 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?

Show 16 quoted lines

> $ 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