Re: [PATCH v10 33/40] environment: add set_index_file()
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 8, 2016, 22:13 UTC
- Message-ID
- <xmqq60raewod.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20160808210337.5038-34-chriscool@tuxfamily.org>
Christian Couder <christian.couder@gmail.com> writes:
Show 18 quoted lines
> 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?