From: Duy Nguyen Date: Thu, 17 Dec 2015 12:36:31 GMT Subject: Re: [PATCH 7/8] config: add core.untrackedCache Message-ID: In-Reply-To: On Wed, Dec 16, 2015 at 4:53 AM, Ævar Arnfjörð Bjarmason wrote: > On Tue, Dec 15, 2015 at 8:40 PM, Junio C Hamano wrote: >> Ævar Arnfjörð Bjarmason 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