Christian Couder <christian.couder@xxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html