Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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?

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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, >

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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 >>>

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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 >>

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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

[PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

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