On 3/1/2018 2:42 AM, Jeff King wrote:
On Wed, Feb 28, 2018 at 01:27:03PM -0800, Junio C Hamano wrote:
Somehow this topic has been hanging without getting further
attention for too long. It's time to wrap it up and moving it
forward. How about this?
-- >8 --
From: Junio C Hamano
On Wed, Feb 28, 2018 at 01:27:03PM -0800, Junio C Hamano wrote:
> Somehow this topic has been hanging without getting further
> attention for too long. It's time to wrap it up and moving it
> forward. How about this?
>
> -- >8 --
> From: Junio C Hamano
> Date: Wed, 28 Feb
Jeff King writes:
> A minor nit, but please use something like:
>
> if (git_env_bool("GIT_TEST_UNTRACKED_CACHE", 0) && ...
>
> so that:
>
> GIT_TEST_UNTRACKED_CACHE=false
>
> does what one might expect, and not the opposite.
>
> Two other thoughts:
>
> - it may be worth
On Tue, Feb 13, 2018 at 12:57 AM, Ben Peart wrote:
>> Another case that could touches a lot of directories over time is
>> switch trees (e.g. "git checkout master" then "checkout next" or worse
>> "checkout v1.0").
>
>
> You're example above makes me wonder if you understand
On 2/12/2018 5:20 AM, Duy Nguyen wrote:
On Wed, Feb 7, 2018 at 9:13 PM, Ben Peart wrote:
On 2/6/2018 7:27 AM, Duy Nguyen wrote:
This is another thing that bugs me. I know you're talking about huge
index files, but at what size should we start this sort of
optimization?
On Wed, Feb 7, 2018 at 9:13 PM, Ben Peart wrote:
>
>
> On 2/6/2018 7:27 AM, Duy Nguyen wrote:
>>
>>
>> This is another thing that bugs me. I know you're talking about huge
>> index files, but at what size should we start this sort of
>> optimization? Writing down a few MBs on
On Mon, Feb 05, 2018 at 02:56:19PM -0500, Ben Peart wrote:
> diff --git a/dir.c b/dir.c
> index 7c4b45e30e..da93374f0c 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -2297,7 +2297,8 @@ int read_directory(struct dir_struct *dir, struct
> index_state *istate,
>
On 2/6/2018 7:27 AM, Duy Nguyen wrote:
This is another thing that bugs me. I know you're talking about huge
index files, but at what size should we start this sort of
optimization? Writing down a few MBs on linux is cheap enough that I
won't bother optimizing (and I get my UNTR extension
On 2/7/2018 5:59 AM, Duy Nguyen wrote:
On Tue, Feb 6, 2018 at 7:55 PM, Duy Nguyen wrote:
On Tue, Feb 6, 2018 at 7:27 PM, Duy Nguyen wrote:
On Tue, Feb 6, 2018 at 8:48 AM, Ben Peart wrote:
With the new behavior, making a change in
On Tue, Feb 6, 2018 at 7:55 PM, Duy Nguyen wrote:
> On Tue, Feb 6, 2018 at 7:27 PM, Duy Nguyen wrote:
>> On Tue, Feb 6, 2018 at 8:48 AM, Ben Peart wrote:
>>> With the new behavior, making a change in dir1/, then calling status would
>>>
Duy Nguyen writes:
> Please don't do that, at least not this way. cache_changed mask should
> reflect all dirty parts in .git/index. If UNTR extension is not marked
> updated, it's legit to just skip generating/writing it down (e.g. if I
> kept the old UNTR extension from the
On Tue, Feb 6, 2018 at 7:27 PM, Duy Nguyen wrote:
> On Tue, Feb 6, 2018 at 8:48 AM, Ben Peart wrote:
>> With the new behavior, making a change in dir1/, then calling status would
>> update the dir1/ untracked cache entry but not write it out. On the next
>>
On Tue, Feb 6, 2018 at 8:48 AM, Ben Peart wrote:
> With the new behavior, making a change in dir1/, then calling status would
> update the dir1/ untracked cache entry but not write it out. On the next
> status, git would detect the change in dir1/ again and update the
On 2/5/2018 4:58 PM, Brandon Williams wrote:
On 02/05, Ben Peart wrote:
The untracked cache saves its current state in the UNTR index extension.
Currently, _any_ change to that state causes the index to be flagged as dirty
and written out to disk. Unfortunately, the cost to write out the
On 02/05, Ben Peart wrote:
> The untracked cache saves its current state in the UNTR index extension.
> Currently, _any_ change to that state causes the index to be flagged as dirty
> and written out to disk. Unfortunately, the cost to write out the index can
> exceed the savings gained by using
Ben Peart writes:
> The untracked cache saves its current state in the UNTR index extension.
> Currently, _any_ change to that state causes the index to be flagged as dirty
> and written out to disk. Unfortunately, the cost to write out the index can
> exceed the savings
The untracked cache saves its current state in the UNTR index extension.
Currently, _any_ change to that state causes the index to be flagged as dirty
and written out to disk. Unfortunately, the cost to write out the index can
exceed the savings gained by using the untracked cache. Since it is a
17 matches
Mail list logo