On Wed, Dec 16, 2015 at 4:53 AM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > On Tue, Dec 15, 2015 at 8:40 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> I still have a problem with the approach from "design cleanliness" >> point of view[...] >> >> In any case I think we already have agreed to disagree on this >> point, so there is no use discussing it any longer from my side. I >> am not closing the door to this series, but I am not convinced, >> either. At least not yet. > > In general the fantastic thing about the git configuration facility is > that it provides both systems administrators and normal users with > what they want. It's possible to configure things system-wide and > override those on a user or repository basis. > > Of course hindsight is 20/20, but I think that given what's been > covered in this thread it's been established that it's categorically > better that if we introduce features like these that they be > configured through the normal configuration facility rather than the > configuration being sticky to the index. A minor note for implementers. We need to check that config is loaded first. read-cache.c, being part of the core, does not bother itself with config loading. And I think so far it has not used any config vars. If a command forgets (*) to load the config, the cache may be deleted (if we do it the safe way). (*) is there any command deliberately avoid loading config? git-clone and git-init are special, but for this particular case it's probably fine. -- 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