From: Ben Peart <peartben@gmail.com>
Date: Tue, 09 May 2017 12:51:11 GMT
Subject: Re: [PATCH 0/1] Preserve the untracked cache across checkout, reset --hard, etc
Message-ID: <1e21e5c4-3440-a82f-b6c5-1a3e00439054@gmail.com>
In-Reply-To: <xmqqy3u639n4.fsf@gitster.mtv.corp.google.com>


On 5/9/2017 1:02 AM, Junio C Hamano wrote:
> David Turner <David.Turner@twosigma.com> writes:
>
>> Can you actually keep the email address as my Twopensource one?  I want to make sure that Twitter, my employer at the time, gets credit for this work (just as I want to make sure that my current employer, Two Sigma, gets credit for my current work).
>>
>> Please feel free to add Signed-off-by: David Turner <dturner@twosigma.com> in case that makes tracking easier.
>>
>> Thanks.
>>
>> WRT the actual patch, I want to note that past me did not do a
>> great job here.  The tests do not correctly check that the
>> post-checkout untracked cache is still valid after a checkout.
>> For example, let's say that previously, the directory foo was
>> entirely untracked (but it contained a file bar), but after the
>> checkout, there is a file foo/baz.  Does the untracked cache need
>> to get updated?
>>
>> Unfortunately, the untracked cache is very unlikely to make it to
>> the top of my priority list any time soon, so I won't be able to
>> correct this test (and, if necessary, correct the code).  But I
>> would strongly suggest that the test be improved before this code
>> is merged.
>>
>> Thanks for CCing me.
> I will try to find time to tweak what was sent to the list here to
> reflect your affiliations better, but marked with DONTMERGE waiting
> for the necessary updates you mentioned above, so that this change
> is not forgotten.  It may turn out to be that copying from src to
> dst like the patch does is all that is needed, or the cache may need
> further invalidation when the copying happens, and I haven't got a
> good feeling that anybody who are familiar with the codepath vetted
> the correctness from seeing the discussion from sidelines (yet).
>
> Thanks.

I've been looking into similar issues with the cache associated with 
using a file system monitor (aka Watchman) 
(https://github.com/git-for-windows/git/compare/master...benpeart:fsmonitor) 
to speed updating the index to reflect changes in the working directory.

I can take a look and see if this patch results in valid results and 
reply to the thread or resubmit as needed.

Ben