Jeff King [off-list ref] writes:
... But finding every file means
we have to traverse areas that git otherwise wouldn't look at, which
might mean going to disk to pull in all of the "foo/" directory
structure (which is less likely to be cached, since the rest of git
isn't touching it), even though it may not even be of interest to us.
Yes, that is why it is adequate for us use COLLECT_IGNORED in "git add"
and give "foo/ is outside---you as an intelligent human should be able to
infer that your foo/bar is also" without double traversal.
Eric's tool might want the same abbreviated information if it is just
relaying our output to an intelligent human. Or it might want to get all
paths if it wants to operate on them itself. Knowing VC I chose to
illustrate how to do the latter, but in the real implementation, we may
want --show-ignored=normal vs --show-ignored=expanded to support both
uses.
Junio C Hamano [off-list ref] writes:
Jeff King [off-list ref] writes:
quoted
... But finding every file means
we have to traverse areas that git otherwise wouldn't look at, which
might mean going to disk to pull in all of the "foo/" directory
structure (which is less likely to be cached, since the rest of git
isn't touching it), even though it may not even be of interest to us.
Yes, that is why it is adequate for us use COLLECT_IGNORED in "git add"
and give "foo/ is outside---you as an intelligent human should be able to
infer that your foo/bar is also" without double traversal.
Eric's tool might want the same abbreviated information if it is just
relaying our output to an intelligent human. Or it might want to get all
paths if it wants to operate on them itself. Knowing VC I chose to
illustrate how to do the latter, but in the real implementation, we may
want --show-ignored=normal vs --show-ignored=expanded to support both
uses.
Or rather -i / --ignored-files[=(no|normal|all)], default to 'normal'
in the '--ignored-files' form (without optional <mode>), similarly
to currently existing -u / --untracked-files option to git-status.
Let's not introduce yet another CLI inconsistency^TM in Git... ;-)
--
Jakub Narebski
Poland
ShadeHawk on #git
On Sat, Apr 10, 2010 at 11:27:39AM -0700, Junio C Hamano wrote:
quoted
... But finding every file means
we have to traverse areas that git otherwise wouldn't look at, which
might mean going to disk to pull in all of the "foo/" directory
structure (which is less likely to be cached, since the rest of git
isn't touching it), even though it may not even be of interest to us.
Yes, that is why it is adequate for us use COLLECT_IGNORED in "git add"
and give "foo/ is outside---you as an intelligent human should be able to
infer that your foo/bar is also" without double traversal.
It would be adequate here, too, if we want to know whether a specific
file is ignored. It just takes more work from the caller. But Eric has
already said he would prefer to just get all files, so let's go with
what you wrote.
If another caller wants a more restricted but efficient interface later,
we can add it as you suggest (or more likely, they want to check a
particular _set_ of files, so we don't want to do a full traversal
anyway. We would want to get their list of candidates and traverse just
enough of the .gitignore stack to get answers for their set).
-Peff