Jeff King [off-list ref] writes:
No, I don't think anybody is working on it at the moment (at least I
do not see anything near the time of that old discussion, nor do I
recall it being discussed since).
+cc Clemens, in case he had any work-in-progress as a result that did
not end up getting published.
I think the way the codepath for -i feeds path to excluded() is wrong.
The excluded() interface relies on the fact that the caller has
already checked foo/ before calling it for foo/bar; when asked to
see if "foo/bar" is excluded, it does not consider if "foo/" is
excluded---the caller should have already checked it.
The loop for cached/stage case in builtin/ls-files.c::show_files()
needs to learn to be more careful when DIR_SHOW_IGNORED is set in
dir->flags. It needs to call a new helper function that notices
that the check is walking into a different directory from the path
it checked last, and feed leading directories to excluded(), or
something like that, instead of directly calling !excluded().
On Fri, Jun 1, 2012 at 11:03 PM, Junio C Hamano [off-list ref] wrote:
Jeff King [off-list ref] writes:
quoted
No, I don't think anybody is working on it at the moment (at least I
do not see anything near the time of that old discussion, nor do I
recall it being discussed since).
+cc Clemens, in case he had any work-in-progress as a result that did
not end up getting published.
I think the way the codepath for -i feeds path to excluded() is wrong.
The excluded() interface relies on the fact that the caller has
already checked foo/ before calling it for foo/bar; when asked to
see if "foo/bar" is excluded, it does not consider if "foo/" is
excluded---the caller should have already checked it.
Sparse checkout deals with the exact same problem and it reconstructs
a tree structure from cache list, before feeding to excluded(). I
thought of generalizing it (e.g. for this case), but with v5 in
progress, we'll probably have tree-based index soon. "ls-files -i"
could be fixed by then.
--
Duy
@Jeff: Thank you for the clarification. I didn't want to appear pushy, I
just wanted to make sure that I did everything right and that my mail
won't get ignored/filtered because of some breach of protocol.
@Junio, Duy: Thanks for starting/proposing work on this!
thanks,
Christoph
On 06/02/2012 12:33 PM, Nguyen Thai Ngoc Duy wrote:
On Fri, Jun 1, 2012 at 11:03 PM, Junio C Hamano[off-list ref] wrote:
quoted
Jeff King[off-list ref] writes:
quoted
No, I don't think anybody is working on it at the moment (at least I
do not see anything near the time of that old discussion, nor do I
recall it being discussed since).
+cc Clemens, in case he had any work-in-progress as a result that did
not end up getting published.
I think the way the codepath for -i feeds path to excluded() is wrong.
The excluded() interface relies on the fact that the caller has
already checked foo/ before calling it for foo/bar; when asked to
see if "foo/bar" is excluded, it does not consider if "foo/" is
excluded---the caller should have already checked it.
Sparse checkout deals with the exact same problem and it reconstructs
a tree structure from cache list, before feeding to excluded(). I
thought of generalizing it (e.g. for this case), but with v5 in
progress, we'll probably have tree-based index soon. "ls-files -i"
could be fixed by then.