Junio C Hamano <gitster@xxxxxxxxx> writes: > Jeff King <peff@xxxxxxxx> 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. 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html