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
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
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
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
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
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
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
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
(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
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
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
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
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
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
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:
>>>
>>>
Æ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
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
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
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.
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
Æ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
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
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
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
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
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
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
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
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.
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
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
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
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
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
34 matches
Mail list logo