Am 30.08.21 um 22:49 schrieb Jeff King: > On Mon, Aug 30, 2021 at 08:22:25PM +0200, René Scharfe wrote: > >>> It however may not be a bad idea to catch these code paths where a >>> local variable masks 'ignore_case' (and possibly other globals) and >>> rename these local ones to avoid a mistake like this. >> >> The name itself is OK, I think, but using it at global scope is >> confusing. -Wshadow can help find such cases, but not this one, as >> test-hashmap.c doesn't include the global declaration. Moving the >> global into a struct to provide a poor man's namespace would fix this >> for all namesakes, assisted by the compiler. We'd then access it as >> the_config.ignore_case or even the_config.core.ignore_case. >> >> Moving all config-related variables would be quite noisy, I guess, >> and probably conflict with lots of in-flight patches, but might be >> worth it. > > Really most of these ought to be in the repository struct anyway, I > would think. The value of ignore_case comes from core.ignorecase, which > is going to be repository-specific. We are probably doing the wrong > thing already by looking at the parent core.ignorecase value when > operating in an in-process submodule, but nobody noticed because it's > quite unlikely for a submodule to have a different setting than the > parent. Good point. So fspathcmp() and friends would need a repo parameter. :-| René
