On Tue, Dec 15, 2015 at 10:05:57PM -0800, Junio C Hamano wrote:
> Junio C Hamano <gits...@pobox.com> 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 this is merely a boolean
> > configuration is the real source of the confusion, and introducing a
> > config that overrules what the user has stored in the index needs to
> > add complexity.
> >
> > The additional complexity may (or may not) be justifiable, but in
> > any case "all other things being equal, this is a config" feels like
> > a flawed observation.
>
> To put it another way, the "bit" in the index (i.e. the presence of
> the cached data) is "Am I using the feature now?". The effect of
> the feature has to (and is designed to) persist, as it is a cache
> and you do not want a stale cache to give you wrong answers. There
> is no "Do I want to use the feature?" preference, in other words.
>
> And I do not mind creating such a preference bit as a configuration.
>
> That is why I suggested such a configuration to cause the equivalent
> of "update-index --untracked-cache" when a new index is created from
> scratch (as opposed to the case where the previously created cache
> data is carried forward across read_cache() -> do things to the
> index -> write_cache() flow). Doing it that way will not have to
> involve additional complexity that comes from the desire that
> setting a single configuration on (or off) has to suddenly change
> the behaviour of an index file that is already using (or not using)
> the feature.
I think we may actually be thinking of the same thing. Naively, I would
expect:
- if there is untracked cache data in the index, we will make use of
it when enumerating untracked files (and my understanding is that if
it is stale, we can detect that)
- if core.untrackedCache is set, we will update and write out an
untracked cache when we are enumerating the untracked files
- 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 drop it,
but my understanding is that is not necessary for correctness, but
only as a possible optimization).
You could have a config option for "if there is a cache there, pretend
it isn't and ignore it", but I don't see much point.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
