Re: [PATCH 7/8] config: add core.untrackedCache

Duy Nguyen writes: > Sounds good, except.. > >> When write_index() writes out an index that wasn't initialized from >> the filesystem, a new UNTR gets added only when the configuration is >> set to 'true' and there is no in-core UNTR already. > > Do we really need this? We

Re: [PATCH 7/8] config: add core.untrackedCache

On Thu, Dec 24, 2015 at 2:56 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Duy Nguyen writes: >> >>> In that case we can just check config once in read_index_from and >>> destroy UNTR extension. Or the middle ground, we check

Re: [PATCH 7/8] config: add core.untrackedCache

On Thu, Dec 24, 2015 at 8:56 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Duy Nguyen writes: >> >>> In that case we can just check config once in read_index_from and >>> destroy UNTR extension. Or the middle ground, we check

Re: [PATCH 7/8] config: add core.untrackedCache

Junio C Hamano writes: > Duy Nguyen writes: > >> In that case we can just check config once in read_index_from and >> destroy UNTR extension. Or the middle ground, we check config once in >> that place, make a note in struct index_state, and make

Re: [PATCH 7/8] config: add core.untrackedCache

On Tue, Dec 22, 2015 at 1:30 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >> On Thu, Dec 17, 2015 at 2:44 PM, Jeff King wrote: >>> I think we may actually be thinking of the same thing. Naively, I would >>> expect: >>> >>> .. >>> - if

Re: [PATCH 7/8] config: add core.untrackedCache

Duy Nguyen writes: > In that case we can just check config once in read_index_from and > destroy UNTR extension. Or the middle ground, we check config once in > that place, make a note in struct index_state, and make invalidate_* > check that note instead of config file. The

Re: [PATCH 7/8] config: add core.untrackedCache

Duy Nguyen writes: > On Thu, Dec 17, 2015 at 2:44 PM, Jeff King wrote: >> I think we may actually be thinking of the same thing. Naively, I would >> expect: >> >> .. >> - if there is cache data in the index but that config flag is not set, >> presumably

Re: [PATCH 7/8] config: add core.untrackedCache

On Thu, Dec 17, 2015 at 1:36 PM, Duy Nguyen wrote: > 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

Fwd: [PATCH 7/8] config: add core.untrackedCache

(Sorry I sent this one privately to Duy by mistake too.) -- Forwarded message -- From: Christian Couder <christian.cou...@gmail.com> Date: Fri, Dec 18, 2015 at 11:35 PM Subject: Re: [PATCH 7/8] config: add core.untrackedCache To: Duy Nguyen <pclo...@gmail.com> On

Fwd: [PATCH 7/8] config: add core.untrackedCache

Sorry I sent this privately to Peff by mistake (once again). -- Forwarded message -- From: Christian Couder <christian.cou...@gmail.com> Date: Fri, Dec 18, 2015 at 11:09 PM Subject: Re: [PATCH 7/8] config: add core.untrackedCache To: Jeff King <p...@peff.net> On

Re: [PATCH 7/8] config: add core.untrackedCache

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

Re: [PATCH 7/8] config: add core.untrackedCache

On Thu, Dec 17, 2015 at 2:44 PM, Jeff King wrote: > I think we may actually be thinking of the same thing. Naively, I would > expect: > > .. > - if there is cache data in the index but that config flag is not set, > presumably we would not update it (we could even explicitly

Re: [PATCH 7/8] config: add core.untrackedCache

On Tue, Dec 15, 2015 at 10:05:57PM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > This is why the_index.has_untracked_cache is not just a simple "Do I > > want to use this feature?" boolean configuration. The index also > > stores the real data, and "Am I using

Re: [PATCH 7/8] config: add core.untrackedCache

On Tue, Dec 15, 2015 at 10:49 AM, Torsten Bögershausen wrote: > On 15.12.15 10:34, Christian Couder wrote: >> On Mon, Dec 14, 2015 at 10:30 PM, Junio C Hamano wrote: >>> Junio C Hamano writes: >>> >>> The primary reason why I do not like your

Re: [PATCH 7/8] config: add core.untrackedCache

On Tue, Dec 15, 2015 at 11:02 AM, Duy Nguyen wrote: > On Tue, Dec 15, 2015 at 4:34 PM, Christian Couder > wrote: >> On Mon, Dec 14, 2015 at 10:30 PM, Junio C Hamano wrote: >>> Junio C Hamano writes: >>> >>>

Re: [PATCH 7/8] config: add core.untrackedCache

Ævar Arnfjörð Bjarmason writes: > The way the "config decides" patch series deals with this is that if > you have the UC information in the index and the configuration is set > to core.untrackedCache=false the UC will be removed from the index. > > Otherwise you would indeed

Re: [PATCH 7/8] config: add core.untrackedCache

On Mon, Dec 14, 2015 at 10:30 PM, Junio C Hamano wrote: > Junio C Hamano writes: > > The primary reason why I do not like your "configuration decides" is > it will be a huge source of confusions and bugs. Imagine what > should happen in this sequence, and

Re: [PATCH 7/8] config: add core.untrackedCache

On Tue, Dec 15, 2015 at 4:34 PM, Christian Couder wrote: > On Mon, Dec 14, 2015 at 10:30 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >> The primary reason why I do not like your "configuration decides" is >> it will be

Re: [PATCH 7/8] config: add core.untrackedCache

On 15.12.15 10:34, Christian Couder wrote: > On Mon, Dec 14, 2015 at 10:30 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >> The primary reason why I do not like your "configuration decides" is >> it will be a huge source of confusions and bugs.

Re: [PATCH 7/8] config: add core.untrackedCache

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

Re: [PATCH 7/8] config: add core.untrackedCache

Ævar Arnfjörð Bjarmason writes: > 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

Re: [PATCH 7/8] config: add core.untrackedCache

Jeff King writes: >> If the feature is something only those with really large repositories >> care about, is it a good trade-off to make everybody pay the runtime >> cost and make code more complex and fragile? I am not yet convinced. > > I'm not sure I understand the runtime and

Re: [PATCH 7/8] config: add core.untrackedCache

Junio C Hamano writes: > This is why the_index.has_untracked_cache is not just a simple "Do I > want to use this feature?" boolean configuration. The index also > stores the real data, and "Am I using this feature?" bit goes hand > in hand with that real data. Thinking that

Re: [PATCH 7/8] config: add core.untrackedCache

On Tue, Dec 15, 2015 at 2:04 PM, Ævar Arnfjörð Bjarmason wrote: > On Mon, Dec 14, 2015 at 8:44 PM, Junio C Hamano wrote: > > I'm replying to & quoting from two E-Mails of yours at once here for > clarity & less noise. I'm working wich Christian on getting

Re: [PATCH 7/8] config: add core.untrackedCache

On Mon, Dec 14, 2015 at 8:44 PM, Junio C Hamano wrote: I'm replying to & quoting from two E-Mails of yours at once here for clarity & less noise. I'm working wich Christian on getting this integrated, and we both thought it would be good to have some fresh input on the matter

Re: [PATCH 7/8] config: add core.untrackedCache

On Wed, Dec 16, 2015 at 12:03 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> 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

Re: [PATCH 7/8] config: add core.untrackedCache

On Tue, Dec 15, 2015 at 03:03:14PM -0800, Junio C Hamano wrote: > The thing is, I do not necessarily view this as "configuration". > The way I see the feature is that you say "--untracked" when you > want the states of untracked paths be kept track of in the index, > just like you say "git add

Re: [PATCH 7/8] config: add core.untrackedCache

On Tue, Dec 8, 2015 at 11:43 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Christian Couder writes: >> >>> When we know that mtime is fully supported by the environment, we >>> might want the untracked cache to be

Re: [PATCH 7/8] config: add core.untrackedCache

Junio C Hamano writes: > If you stop thinking that "update-index --untracked-cache" is > somehow a "configuration", things will get clearer to you. > ... >> "git update-index --[no-|force-]untracked-cache" is a bad way, so >> let's make it easy for people to not use it at all.

Re: [PATCH 7/8] config: add core.untrackedCache

Christian Couder writes: > In fact "git update-index --[no-|force-]untracked-cache" is very bad > because it means that two repositories can be configured differently > even if they have the same config files. If you stop thinking that "update-index

Re: [PATCH 7/8] config: add core.untrackedCache

On 08.12.15 18:15, Christian Couder wrote: > When we know that mtime is fully supported by the environment, we > might want the untracked cache to be always used by default without > any mtime test or kernel version check being performed. > For the people which didn't follow the discussion, or

[PATCH 7/8] config: add core.untrackedCache

When we know that mtime is fully supported by the environment, we might want the untracked cache to be always used by default without any mtime test or kernel version check being performed. Also when we know that mtime is not supported by the environment, for example because the repo is shared

Re: [PATCH 7/8] config: add core.untrackedCache

Christian Couder writes: > When we know that mtime is fully supported by the environment, we > might want the untracked cache to be always used by default without > any mtime test or kernel version check being performed. > > Also when we know that mtime is not

Re: [PATCH 7/8] config: add core.untrackedCache

Junio C Hamano writes: > Christian Couder writes: > >> When we know that mtime is fully supported by the environment, we >> might want the untracked cache to be always used by default without >> any mtime test or kernel version check being