On Mon, Mar 16, 2015 at 10:35:18PM -0700, Junio C Hamano wrote: > > It looks like we don't even really care about the value of HEAD. We just > > want to know "is it a git directory?". I think in other places (like > > "git add"), we just do an existence check for "$dir/.git". That would > > not catch a bare repository, but I do not think the current check does > > either (it is looking for submodules, which always have a .git). > > If we wanted to be consistent, perhaps we should be reusing the "is > this a git repository?" check used by the auto-discovery codepath > (setup.c:is_git_directory(), perhaps?), but the idea looks simple > enough and sounds sensible. Yeah, I almost suggested that, but I'm concerned that would make us inconsistent with how we report untracked files. I thought that dir.c used ".git" as a magic token there. But it seems I'm wrong. We do ignore ".git" directly in treat_path(), but treat_directory actually checks resolve_gitlink_ref. I think this will suffer the same problem as Andreas's original issue (e.g., if you run "git ls-files -o"). Likewise, I think dir.c:remove_dir_recurse is in a similar boat. Grepping for resolve_gitlink_ref, it looks like there may be others, too. All of these should be using the same test, I think. Doing that with is_git_directory() is probably OK. It is a little more expensive than we might want for mass-use (it actually opens and parses the HEAD file in each directory), but it quits early when we _don't_ see a git directory, which would be the common case here. -Peff -- 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