Re: ls-files --exclude broken?

From: Daniel Johnson <computerdruid@gmail.com>
Date: Sep 15, 2010, 23:31 UTC
Message-ID: <201009151931.23482.ComputerDruid@gmail.com>
In-Reply-To: <AANLkTimuTHvA+qjqpmz=VkCpTTiRA7imb5+ZyTVmPwYy@mail.gmail.com>

On Wednesday 15 September 2010 18:40:20 Jay Soffian wrote:

Show 9 quoted lines

> 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@peff.net>
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@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>