Re: [PATCH 0/1] Preserve the untracked cache across checkout, reset --hard, etc
- From
Ben Peart <peartben@gmail.com>
- Date
- May 9, 2017, 12:51 UTC
- 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:
Show 33 quoted lines
> 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