On Tue, Jul 26, 2016 at 9:28 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Christian Couder <christian.couder@xxxxxxxxx> writes: > >> Introduce set_index_file() to be able to temporarily change the index file. >> >> 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); > > WHY is glaringly missing. It's used in a4aaa23 (builtin/am: use apply api in run_apply() - 2016-06-27) as a straight conversion of "GIT_INDEX_FILE=xxx git apply" . > Doesn't calling this have a global effect that is flowned upon when > used by a library-ish function? Who is the expected caller in this > series that wants to "libify" a part of the system? 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). But at least read-cache.c has supported multiple indexes for a long time. -- Duy -- 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