Re: [PATCH v10 33/40] environment: add set_index_file()

[Junio C Hamano <gitster@pobox.com>]

Christian Couder <christian.couder@gmail.com> writes:

> Now if someone really needs to use this new function, it should be
> used like this:
>
>     /* Save current index file */
>     old_index_file = get_index_file();
>     set_index_file((char *)tmp_index_file);
>
>     /* Do stuff that will use tmp_index_file as the index file */
>     ...
>
>     /* When finished reset the index file */
>     set_index_file(old_index_file);
>
> It is intended to be used by builtins commands, in fact only `git am`,
> to temporarily change the index file used by libified code.
>
> This is useful when libified code uses the global index, but a builtin
> command wants another index file to be used instead.

That is OK, but I do not think NO_THE_INDEX_COMPATIBILITY_MACROS has
much to do with this hack.  Even if you stop using the_index and
have the caller pass its own temporary index_state, that structure
does *not* know which file to read the (temporary) index from, or
which file to write the (temporary) index to.  In fact, apply.c
already does this in build_fake_ancestor():

    static int build_fake_ancestor(struct patch *list, const char *filename)
    {
            ...
            hold_lock_file_for_update(&lock, filename, LOCK_DIE_ON_ERROR);
            res = write_locked_index(&result, &lock, COMMIT_LOCK);
            ...
    }

As you can see, this function works with a non-standard/default
index file _without_ having to use non-default index_state.  What
the set_index_file() hack allows you to do is to use interface that
does *NOT* pass "filename" like the caller does to this function.

Isn't the mention on NO_THE_INDEX_COMPATIBILITY_MACROS in the added
comments (there are two) pure red-herring?