893

I am getting my feet wet with Git and have the following issue:

My project source tree:

/ | +--src/ +----refs/ +----... | +--vendor/ +----...

I have code (currently MEF) in my vendor branch that I will compile there and then move the references into /src/refs which is where the project picks them up from.

My issue is that I have my .gitignore set to ignore *.dll and *.pdb. I can do a git add -f bar.dll to force the addition of the ignored file which is ok, the problem is I can not figure out to list what files exist that are ignored.

I want to list the ignored files to make sure that I don't forget to add them.

I have read the man page on git ls-files and can not make it work. It seems to me that git ls-files --exclude-standard -i should do what I want. What am I missing?

Improve this question
9
  • 13
    These days, you wouldn't use git-ls-files but rather 'git ls-files' Commented Jun 10, 2009 at 20:40
  • 7
    I plead with you to check riyad's answer as correct since that is the only one that admits there's no guaranteed way to do this using only git commands (including the git clean trick) as demonstrated here. Also, I recommend against the "exclude-from" example in your summary since that factually doesn't pay attention to any .gitignore files. I ask this especially because this page is the top Google response. Commented Oct 26, 2012 at 1:19
  • Quick point on "Summary of what works": the "Git ls-files" man page explains that the "-i" means include excluded files for the ls output. I had the same misunderstanding, until I read 'it slowly'. ;-) Commented May 1, 2014 at 8:07
  • 10
    git status --ignored is the one I prefer: git-scm.com/docs/git-status#Documentation/… Commented Jul 7, 2019 at 2:55
  • 1
    Last time I tried checking this with git clean -dfxn but forgot the n and deleted all my ignored files. DO NOT DO THIS. Commented Mar 7, 2024 at 6:55

12 Answers 12

Reset to default
1008

Notes:

Also interesting (mentioned in qwertymk's answer), you can also use the git check-ignore -v command, at least on Unix (doesn't work in a CMD Windows session, but works in a Windows CMD git bash session)

git check-ignore -- * git check-ignore -v -- *

The second one displays the actual rule of the .gitignore which makes a file to be ignored in your git repo.
On Unix, using "What expands to all files in current directory recursively?" and a bash4+:

git check-ignore **/*

(or a find -exec command)

Note: https://stackoverflow.com/users/351947/Rafi B. suggests in the comments to avoid the (risky) globstar:

git check-ignore -v $(find . -type f -print)

Make sure to exclude the files from the .git/ subfolder though.

CervEd suggests in the comments, to avoid .git/:

find . -not -path './.git/*' | git check-ignore --stdin

Original answer (2009)

git ls-files -i

should work, except its source code indicates:

if (show_ignored && !exc_given) { fprintf(stderr, "%s: --ignored needs some exclude pattern\n", argv[0]);

exc_given?

It turns out it needs one more parameter after the -i to actually list anything.

Try:

git ls-files -i --exclude-from=[Path_To_Your_Global].gitignore

(but that would only list your cached (non-ignored) object, with a filter, so that is not quite what you want)

Example:

$ cat .git/ignore # ignore objects and archives, anywhere in the tree. *.[oa] $ cat Documentation/.gitignore # ignore generated HTML files, *.html # except foo.html which is maintained by hand !foo.html $ git ls-files --ignored \ --exclude='Documentation/*.[0-9]' \ --exclude-from=.git/ignore \ --exclude-per-directory=.gitignore

Actually, in my 'gitignore' file (called 'exclude'), I find a command line that could help you:

F:\prog\git\test\.git\info>type exclude # git ls-files --others --exclude-from=.git/info/exclude # Lines that start with '#' are comments. # For a project mostly in C, the following would be a good set of # exclude patterns (uncomment them if you want to use them): # *.[oa] # *~

So....

git ls-files --ignored --exclude-from=.git/info/exclude git ls-files -i --exclude-from=.git/info/exclude git ls-files --others --ignored --exclude-standard git ls-files -o -i --exclude-standard

Should do the trick.

(Thanks to honzajde pointing out in the comments that git ls-files -o -i --exclude-from... does not include cached files: only git ls-files -i --exclude-from... (without -o) does.)

As mentioned in the ls-files man page, --others is the important part, to show you non-cached, non-committed, normally ignored files.

--exclude_standard is not just a shortcut, but a way to include all standard "ignored patterns" settings.

exclude-standard
Add the standard git exclusions: .git/info/exclude, .gitignore in each directory, and the user's global exclusion file.

Git 2.44 (Q1 2024), batch 13, clarifies the documentation where the --exclude-per-directory option was marked as deprecated, which confused readers into thinking there may be a plan to remove it in the future, which was not our intention.

See commit 0009542 (24 Jan 2024) by Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster -- in commit bbc8c05, 02 Feb 2024)

ls-files: avoid the verb "deprecate" for individual options

When e750951 ("ls-files: guide folks to --exclude-standard over other --exclude* options", 2023-01-13, Git v2.40.0-rc0 -- merge listed in batch #13) updated the documentation to give greater visibility to the --exclude-standard option, it marked the --exclude-per-directory option as "deprecated".

While it is technically correct that being deprecated does not necessarily mean it is planned to be removed later, it seems to cause confusion to readers, especially when we merely mean

The option Y can be used to achieve the same thing as the option X much simpler. To those of you who aren't familiar with either X or Y, we would recommend to use Y when appropriate.

This is especially true for --exclude-standard vs the combination of more granular --exclude-from and --exclude-per-directory options.
It is true that one common combination of the granular options can be obtained by just giving the former, but that does not necessarily mean a more granular control is not necessary.

State the reason why we recommend readers --exclude-standard in the description of --exclude-per-directory, instead of saying that the option is deprecated.
Also, spell out the recipe to emulate what --exclude-standard does, so that the users can give it minute tweaks (like "do the same as Git Porcelain, except I do not want to read the global exclusion file from core.excludes").

git ls-files now includes in its man page:

directory and its subdirectories in . If you are trying to emulate the way Porcelain commands work, using the --exclude-standard option instead is easier and more thorough.

git ls-files now includes in its man page:

Generally, you should be able to use --exclude-standard when you want the exclude rules applied the same way as what Porcelain commands do. To emulate what --exclude-standard specifies, you can give --exclude-per-directory=.gitignore, and then specify:

  1. The file specified by the core.excludesfile configuration variable, if exists, or the $XDG_CONFIG_HOME/git/ignore file.

  2. The $GIT_DIR/info/exclude file.

via the --exclude-from= option.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

@VocC, from my understanding of these tests, The answer you recommend at the top simply can have big flaws. That's why I would normally recommend riyad's answer instead.
Since Git v2.13.2 Release: git status --ignored seems it also show untracked files: github.com/git/git/blob/master/Documentation/RelNotes/…
@MikeD To make the */ work (or actually, you can just do **) you need globstar to be set shopt -s globstar after that it should work.
786
+300

There is a much simpler way to do it (git 1.7.6+):

git status --ignored

See Is there a way to tell git-status to ignore the effects of .gitignore files?

Improve this answer

5 Comments

My version is 1.7.6. Another version 1.7.5.1 is the one that requires -s. You may try git status -h to see if --ignored is supported
I tried every solution on this page. This is the best one. It shows both files and directories. This feature was probably not available back when this question was originally asked. (By the way, all of the solutions won't work properly with a brand new "git init" until you've at least staged changes.)
This is certainly much better than the accepted answer. It is also much safer than the git clean -ndX solution, because the rare situation when one mistakenly forgets the flags will have an irrevocable effect on the repository, since untracked files are deleted. So it is dangerous. On the contrary git status --ignored is always safe, even when erroneously typed and it's natural to remember.
This solution worked on Windows. I recommend using cmd rather than PowerShell to run this. if you intend to read the output in the console as the dark red text is difficult to read on a dark blue background.
Or git status --ignored --untracked-files=all to display individual files in ignored directories.
424

Another option that's pretty clean (No pun intended.):

git clean -ndX

Explanation:

$ git help clean git-clean - Remove untracked files from the working tree -n, --dry-run - Don't actually remove anything, just show what would be done. -d - Remove untracked directories in addition to untracked files. -X - Remove only files ignored by Git.

Note: This solution will not show ignored files that have already been removed.

Improve this answer

3 Comments

Nifty... however the reason I asked the original question was so that I could make sure that vendor files (*.dll) that were supposed to be there were... so deleting them would not be the desired result. HOWEVER: this is good to know as I have changed my strategy from ignoreing *.dll to ignoring my build output folder (but not my vendor folders). This would be a good alternative to make clean and very helpful on a build server.
I'm using git version 1.7.0.4, and the two commands ('git ls-files -o -i --exclude-standard', 'git clean -dXn') are not equivalent. The first show me 4 files, and the second only two. (.gitignore~, index.php~, sql/create_users.sql~, www/index.php~) (Would remove .gitignore~, Would remove index.php~). Am I missins something here?
@VonC, sweet! Thanks! @Cesar, I'm not sure. I'm not so familiar with git ls-files -o -i --exclude-standard. git clean -dXn has always been what I wanted but doesn't show ignored files that have already been removed. git ls-files -o -i --exclude-standard might do that. So, that might be what's causing the difference.
45

While generally correct your solution does not work in all circumstances. Assume a repo dir like this:

# ls **/* doc/index.html README.txt tmp/dir0/file0 tmp/file1 tmp/file2 doc: index.html tmp: dir0 file1 file2 tmp/dir0: file0

and a .gitignore like this:

# cat .gitignore doc tmp/*

This ignores the doc directory and all files below tmp. Git works as expected, but the given command for listing the ignored files does not. Lets have a look at what git has to say:

# git ls-files --others --ignored --exclude-standard tmp/file1 tmp/file2

Notice that doc is missing from the listing. You can get it with:

# git ls-files --others --ignored --exclude-standard --directory doc/

Notice the additional --directory option.

From my knowledge there is no one command to list all ignored files at once. But I don't know why tmp/dir0 does not show up at all.

Improve this answer

1 Comment

This does it all at once, and expands the directories: (git ls-files -oi --exclude-standard; git ls-files -oi --exclude-standard --directory) | perl -nle '$seen{$_}++||next;if(-d){system"find",$_,"-type","f"}else{print}'
25

Git now has this functionality built in

git check-ignore *

Of course you can change the glob to something like **/*.dll in your case

Git Reference

Improve this answer

3 Comments

git check-ignore **/* to include files in subdirectories
this only lists the top level dicrectories.
Too bad that the built-in is not human-readable, for example, it list everything in vendor and node_modules directories, see my answer for a human-readable version: stackoverflow.com/a/66922010/8740349
18

Here's how to print the complete list of files in the working tree which match patterns located anywhere in Git's multiple gitignore sources (if you're using GNU find):

$ cd {your project directory} $ find . -path ./.git -prune -o -print \ | git check-ignore --no-index --stdin --verbose

It will check all the files in the current branch of the repository (unless you've deleted them locally).

And it identifies the particular gitignore source lines, as well.

Git continues to track changes in some files which match gitignore patterns, simply because those files were added already. Usefully, the above command displays those files, too.

Negative gitignore patterns are also matched. However, these are easily distinguishable in the listing, because they begin with !.

If you're using Windows, Git Bash includes GNU find (as revealed by find --version).

If the list is long (and you have rev), you can display them by extension (somewhat), too:

$ cd {your project directory} $ find . -path ./.git -prune -o -print \ | git check-ignore --no-index --stdin --verbose \ | rev | sort | rev

For more details, see man find, man git-check-ignore, man rev, and man sort.

The point of this whole approach is that Git (the software) is changing rapidly and is highly complex. By contrast, GNU's find is extremely stable (at least, in its features used here). So, anyone who desires to be competitive by displaying their in-depth knowledge of Git will answer the question in a different way.

What's the best answer? This answer deliberately minimizes its reliance on Git knowledge, toward achieving the goal of stability and simplicity through modularity (information isolation), and is designed to last a long time.

Improve this answer

Comments

15

It should be sufficient to use 

git ls-files --others -i --exclude-standard

as that covers everything covered by

git ls-files --others -i --exclude-from=.git/info/exclude

therefore the latter is redundant.

You can make this easier by adding an alias to your ~/.gitconfig file:

git config --global alias.ignored "ls-files --others -i --exclude-standard"

Now you can just type git ignored to see the list. Much easier to remember, and faster to type.

If you prefer the more succinct display of Jason Geng's solution, you can add an alias for that like this:

git config --global alias.ignored "status --ignored -s"

However the more verbose output is more useful for troubleshooting problems with your .gitignore files, as it lists every single cotton-pickin' file that is ignored. You would normally pipe the results through grep to see if a file you expect to be ignored is in there, or if a file you don't want to be ignore is in there.

git ignored | grep some-file-that-isnt-being-ignored-properly

Then, when you just want to see a short display, it's easy enough to remember and type

git status --ignored

(The -s can normally be left off.)

Improve this answer

2 Comments

This never worked for me, because you have to manually list those files. git status --ignored works on Debian sid but may be very new… but apparently it got added due to popular demand ;-)
By "works on Debian sid" I assume you mean "works with the version of Git installed by default on Debian sid"? You should really avoid letting yourself be held hostage by the versions of utilities included in your distro. You can upgrade them independently of the distro itself.
6

If you just need a valid list of files ignored (no matter how they got ignored), and without any extra notice and logs.

Once created, anywhere (in Git-bash) run:

git ignore-list

Create it by executing:

git config --global alias.ignore-list "! cd -- \"\${GIT_PREFIX:-.}\" && git ls-files -v \${1:-.} | sed -n -e \"s,^[a-z] \(.*\)$,\${GIT_PREFIX:-./}\1,p\" && git status --ignored --porcelain \${1:-.} 2>/dev/null | sed -n -e \"s/^\(\\!\\! \)\(.*\)$/\2/p\" #"

Example usage, Assuming it's the initial commit and you want to push everything, try:

git ignore-list | xargs git add -f

Notes:

  1. It's tested and works on both macOS and Windows platforms!
  2. Once you cd into a directory, lists only files ignored from that dir (or its sub-dirs).
  3. And lastly, always logs paths relative to root-dir (which contains .git dir, no matter what dir you cd into).

Another useful thing is Human-readability, like if an entire directory is ignored, something like build or node_modules, this will log dir-name only.
While git ls-files --others -i --exclude-standard command logs each and every file (good for xargs).

Improve this answer

Comments

3

I would just do

git status --porcelain --ignored

and to only list the ignored files

git status --porcelain --ignored | grep '^[!][!] '
Improve this answer

Comments

1

You can use fd.

The command to run is:

comm -23 <(fd -HI | sort) <(fd -H | sort)

Please note that in case there is no .git directory and only a .gitignore file (ex. bare repo), you have to specifically tell where the .gitignore file is.

comm -23 <(fd -HI | sort) <(fd -H --ignore-file .gitignore | sort)

To be more specific, use --no-ignore-vcs instead of -I

For more details please check here.

Improve this answer

Comments

-1

Assuming there are a few ignore directories, why not use "git status node/logs/" which will tell you what files are to be added? In the directory I have a text file that is not part of status output, e.g.:

On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add ..." to include in what will be committed)

 node/logs/.gitignore

.gitignore is:

*

!.gitignore

Improve this answer

Comments

-1

(extending the other answers)

Note, git check-ignore uses the committed .gitignore and not the one in your working tree! To play with it without polluting your git history, you might freely try to edit it, and then commit with a git commit --amend.

This problem happens mainly if you need a workaround of the problem, that git doesn't follow directories. Enter in the .gitignore:

dirtokeep/** !dirtokeep/.keep

.keep should be a zero-length file in dirtokeep.

The result will be that everything in dirtokeep will be ignored, except dirtokeep/.keep, which will result that also the dirtokeep directory will be constructed on clone/checkout.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.