git diff for *.cpp files prints nothing in one repository - linux

Question

Once the command git diff *.cpp just stopped printing anything in one repository, despite git diff *.h works fine. git diff works fine for *.cpp files.
What could it be?

Answer 1

The fix is to be careful to run, e.g.:
git diff '*.cpp'
or:
git diff \*.cpp
or more formally:
git diff -- '*.cpp'
or similar.
What's going on here?
Missing from the question: the desired output was a diff for subdir/subfile.cpp, but the top level of the work-tree contained one file named file.cpp or similar.
The problem stems from the fact that you're using a Unix/Linux-style shell, which expands * and other wildcard or glob characters before running the command you enter at the command line. But there is a bit of subtlety here as well.
Because there exists a file named file.cpp in the current directory, when you run:
git diff *.cpp
the shell replaces *.cpp with the names of all the files whose name ends with .cpp, and therefore runs:
git diff file.cpp
Git then dutifully produces the diff—or in this case, no diff since there is no difference—for the one file named file.cpp.
When there are no files named file.cpp or zorg.cpp or similar in the top level directory, however, this shell simply invokes git with arguments diff and *.cpp, as if you had quoted the asterisk. This gives Git the chance to expand the *.cpp argument, and when Git expands it, it does so in a different way than the shell.
Why use --?
The git diff command takes a number of options, such as -s, -p, -w, --name-status, --name-only, and so on.
Depending on what files you have, suppose you want a diff listing for the file named -z in the current directory. If you then run:
git diff -z
Git thinks you mean to supply the -z option, rather than to get a diff listing for the file named -z. A similar problem applies if you want diffs for -z* and the like.
In general, you can work around this problem by using the file name ./-z instead of just -z. Since ./-z does not start with -, Git is not fooled into thinking it's an option. But this problem is more general, and strikes in other cases (other commands) as well. For instance, suppose you have a file named develop and you run:
git checkout develop
Git will think you mean to check out the branch named develop.
All Git commands accept -- as a separator, generally meaning there no more options: anything after this point is an argument instead. For git diff, anything after -- is treated as a pathspec, which includes doing glob expansion, provided the glob characters made it past the shell.
This is what the syntax description in the SYNOPSIS section of the git diff documentation means:
git diff [<options>] [<commit>] [--] [<path>...]
git diff [<options>] --cached [<commit>] [--] [<path>...]
git diff [<options>] <commit> <commit> [--] [<path>...]
git diff [<options>] <blob> <blob>
git diff [<options>] --no-index [--] <path> <path>
The square brackets indicate that something is optional, so all the options are optional. The angle brackets indicate that some argument should be replaced with a string that meets the requirements of the type inside the brackets. The literal -- or other literal options imply that you should type those characters literally—so git diff --cached requires the literal string --cached, for instance. Last, the ... means "repeat the previous as often as you like".
Since the literal string -- is optional, you don't have to enter it—but if you do, everything after it must have the form of a <path>. That form is quite general: almost any character is valid. The documentation is missing a cross-reference to the definition of a pathspec, though (and probably should use <pathspec>, not just <path>, here). The full description of pathspecs is in the gitglossary.

Answer 2

So I have one .cpp file in the repository root directory, and so git diff *.cpp now prints changes only for this file, while git diff '*.cpp' works fine for all files in subdirectories.