On Wednesday 15 September 2010 18:40:20 Jay Soffian wrote:
> Am I missing something really obvious here?
> kore:~/Repos/git (master)$ git ls-files | wc -l
> 2009
> kore:~/Repos/git (master)$ git ls-files -x \* | wc -l
> 2009
> kore:~/Repos/git (master)$ git ls-files -i -x \* | wc -l
> 2009
> kore:~/Repos/git (master)$ git version
> git version 1.7.3.rc1.5.g95127
For fun, I bisected this. This behavior changed in the following commit.
Before this, it worked as you expected. The other replies seem to explain this
more.
b5227d80aee5173bfda6aa43a890d03110b0df26 is the first bad commit
commit b5227d80aee5173bfda6aa43a890d03110b0df26
Author: Jeff King <peff@xxxxxxxx>
Date: Mon Oct 12 01:11:57 2009 -0400
ls-files: excludes should not impact tracked files
In all parts of git, .gitignore and other exclude files
impact only how we treat untracked files; they should have
no effect on files listed in the index.
This behavior was originally implemented very early on in
9ff768e, but only for --exclude-from. Later, commit 63d285c
accidentally caused us to trigger the behavior for
--exclude-per-directory.
This patch totally ignores excludes for files found in the
index. This means we are reversing the original intent of
9ff768e, while at the same time fixing the accidental
behavior of 63d285c. This is a good thing, though, as the
way that 9ff768e behaved does not really make sense with the
way exclusions are used in modern git.
Signed-off-by: Jeff King <peff@xxxxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
Attachment:
signature.asc
Description: This is a digitally signed message part.