RE: [PATCH v7 06/12] ls-files: Add support in ls-files to display the fsmonitor valid bit

-----Original Message-----
From: David Turner [mailto:David.Turner@twosigma.com]
Sent: Tuesday, September 19, 2017 5:27 PM
To: 'Ben Peart' <redacted>; Ben Peart
[off-list ref]
Cc: avarab@gmail.com; christian.couder@gmail.com; git@vger.kernel.org;
gitster@pobox.com; johannes.schindelin@gmx.de; pclouds@gmail.com;
peff@peff.net
Subject: RE: [PATCH v7 06/12] ls-files: Add support in ls-files to display the
fsmonitor valid bit

quoted

-----Original Message-----
From: Ben Peart [mailto:peartben@gmail.com]
Sent: Tuesday, September 19, 2017 4:45 PM
To: David Turner <redacted>; 'Ben Peart'
[off-list ref]
Cc: avarab@gmail.com; christian.couder@gmail.com; git@vger.kernel.org;
gitster@pobox.com; johannes.schindelin@gmx.de; pclouds@gmail.com;
peff@peff.net
Subject: Re: [PATCH v7 06/12] ls-files: Add support in ls-files to
display the fsmonitor valid bit



On 9/19/2017 3:46 PM, David Turner wrote:

quoted

quoted

-----Original Message-----
From: Ben Peart [mailto:benpeart@microsoft.com]
Sent: Tuesday, September 19, 2017 3:28 PM
To: benpeart@microsoft.com
Cc: David Turner <redacted>; avarab@gmail.com;
christian.couder@gmail.com; git@vger.kernel.org; gitster@pobox.com;
johannes.schindelin@gmx.de; pclouds@gmail.com; peff@peff.net
Subject: [PATCH v7 06/12] ls-files: Add support in ls-files to
display the fsmonitor valid bit

Add a new command line option (-f) to ls-files to have it use
lowercase letters for 'fsmonitor valid' files

Signed-off-by: Ben Peart <redacted>
---
  builtin/ls-files.c | 8 ++++++--
  1 file changed, 6 insertions(+), 2 deletions(-)

This is still missing the corresponding documentation patch.

Sorry for the confusion.

Thanks for following up.

quoted

quoted

10/12 (no reply, haven't checked whether same issue but I assume
same issue since the new case I mentioned isn't added)

It wasn't a bug so I didn't "fix" it.  I just sent an explanation and
patch demonstrating why. You can find it here:

I was concerned about the case of an untracked file inside a directory that
contains no tracked files.  Your patch in this mail treats dir3 just like dir1 and
dir2.  I think you ought to test the case of a dir with no tracked files.

In the case where there is an untracked file inside a directory that contains no tracked files, git will (as shown by the "failing" test) actually find the untracked file.  This is the correct/expected behavior.  The test failure is just indicating that the optimization of not searching that directory for untracked files was not able to occur (because there was no entry in the untracked cache for that directory).

After more careful checking, it looks like this case does work, but it's still
worth testing.