Again, we'll use the data-model repository from the previous example.

For specific file information, we can use the ls-files command to get information about files in the working tree and the staging area. By default, git ls-files will show the files in the staging area, as shown in the following command:

$ git ls-files
README.md
a_sub_directory/readme
another-file.txt
cat-me.txt
hello_world.c

Note this includes all files in the staging area (the tree state at the latest commit, HEAD) and files added since. The status command shows the changes between HEAD and staging area and the staging area and working tree. We can try to create a new file and see what happens using the following command:

$ echo 'Just testing...' > test.txt
$ git ls-files
README.md
a_sub_directory/readme
another-file.txt
cat-me.txt
hello_world.c

If we add the test.txt file to the staging area, we get the following output:

$ git add test.txt
$ git ls-files
README.md
a_sub_directory/readme
another-file.txt
cat-me.txt
hello_world.c
test.txt

By default, ls-files shows only the current content of the staging area, but let's see some other options. We can filter the output to only show modified files with the -m, --modified option, as shown in the following command:

$ echo "Another fine line" >> another-file.txt # Update tracked file
$ git ls-files –m
another-file.txt

The ls-files command can also show files not tracked by Git but that exist in the work area. If we can remove the test.txt file from the staging area, the file is untracked and we can see that it shows up in the ls-files output with the -o, --others option:

$ git reset HEAD test.txt
$ git ls-files --others
test.txt

The ls-files command can also be used to show which files are ignored by Git with the -i, --ignored option. So, we'll add an exclude pattern on .txt files to .gitignore and check the output of ls-files with the standard exclude patterns (.gitignore in each directory, .git/info/exclude, and ~/.gitignore):

$ echo '*.txt' >> .gitignore
$ git ls-files -i --exclude-standard
another-file.txt
cat-me.txt

This showed two files already tracked by Git that match the exclude pattern, probably not really what we wanted. Let's try it again but this time on untracked files with the -o, --others option:

$ git ls-files -o -i --exclude-standard
test.txt

This matches, as expected, the untracked files in the working directory, which are ignored in the .gitignore file.

Let's clean up for the next example:

$ git reset --hard origin/master
$ git clean -xfd

The ls-files command can also come in handy when performing merges that result in conflicts. With the --unmerged option, the output will only show files that have merge conflicts that haven't been fixed (added). To explore this, we can merge the feature/2 branch into master:

$ git merge origin/feature/2
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Recorded preimage for 'README.md'
Automatic merge failed; fix conflicts and then commit the result.

We can check git status to see which files have conflicts:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
You have unmerged paths.
  (fix conflicts and run "git commit")

Changes to be committed:

  new file:   HelloWorld.java
  new file:   hello_world.pl
  new file:   hello_world.py

Unmerged paths:
  (use "git add <file>..." to mark resolution)

  both modified:      README.md

Let's see what the --unmerged option gives in the output:

$ git ls-files --unmerged
100644 23493f6b1edfafbee958d6dacaa863b1156850b7 1  README.md
100644 f21dc2804e888fee6014d7e5b1ceee533b222c15 2  README.md
100644 c4e7c18f3b31cd1d6fabeda4d7b009e3b4f12edb 3  README.md

As expected, the output only shows the conflicted file, README.md, but in three versions. The output is pretty similar to that of ls-tree, which we saw earlier; the first column and second column represent the file mode and the SHA-1 ID, respectively. The third column is different though and is the stage number of the object. Here stage 0 represents the current working tree (not shown previously), but when a conflict arises, the stage number is used to distinguish between the different versions. Stage 1 represents the file where the other differences derive from, that is, the merge-base for that file. Stage 2 and 3 represent the same files, but with different revisions, as they were in their respective branches before the merge. If we want, we can check the revisions of the file with the cat-file or the show command. The --unmerged option also makes it easy to get a list of unmerged files when filtered a bit:

$ git ls-files --unmerged | cut -f 2 | sort -u
README.md

The output is much cleaner than git status, which also shows possible content in the staging area and untracked files.