On Tue, Dec 20 2022, Junio C Hamano wrote: > Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > >>> That's correct, although even if that were the case that wouldn't >>> be an issue with this migration, as we'd have been using >>> "the_index" before, just indirectly through a macro. >> >> Indeed, I'm just not convinced that it is worth removing the macro in >> library code without changing to take a struct istate (I don't see the >> existence of the macro itself as a problem as I think it is just a >> symptom of the real problem) but I seem to be in the minority on that >> point. > > True. > > Many subcommands need to deal only with the_index and no other > index, so for the implementations of the top-level subcommands that > work only in a single repository, the macros are not by themselves > problems. The deeper parts of the system that we want to reuse by > libifying of course eventually need to learn to take an arbitrary > "istate" and NO_THE_INDEX_COMPATIBILITY_MACROS mechanism (and its > successor USE_THE_INDEX_COMPATIBILITY_MACROS, probably) was a great > approach for that goal. I'm not sure what to make of this comment & this series not having been picked up (perhaps I'm reading too much into that), that you'd like to keep USE_THE_INDEX_COMPATIBILITY_MACROS? This side-thread is discussing a theoretical issue. Phillip was saying (if I understand him correctly) that if we were using "the_index" in libraries we should fix that, I was agreeing, but saying that if that were the case this series would still be a good step forward, we could fix those issues later. It looks like we disagreed on the "later" part of that. But in any case, as noted at the start of this thread there are no such library users, so it's a moot point.
