OK, so there seems to be some misunderstanding. The article over at the pro git site about gitignore does refer to the .gitignore file, and not to the command. The command referred to in the other question is not part of git, but of a package called git extras instead.
After giving it some more thought I thnink I'm starting to get what's confusing here. You've just quoted (a part) the order in which git evaluates ignore patterns. On the very top of this order are patterns from the command line
. These are all built-in and custom (like in the referenced answer) commands that handle git ignore patterns.
The second quote is probably best explained by the examples at the bottom of the gitignore manpage. I'm talking about:
$ git status
[...]
# Untracked files:
[...]
# Documentation/foo.html
# Documentation/gitignore.html
# file.o
# lib.a
# src/internal.o
[...]
$ cat .git/info/exclude
# 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 status
[...]
# Untracked files:
[...]
# Documentation/foo.html
[...]
It is also perfectly valid to place the gitignore file anywhere in your project, please refer to the official documentation on gitignore again:
Git normally checks multiple sources, with the following order of precedence, from highest to lowest:
- command line
- a .gitignore file in the same directory as the path, or in any parent directory, with patterns in the higher level files (up to the toplevel of the work tree) being overridden by those in lower level files down to the directory containing the file. These patterns match relative to the location of the .gitignore file. A project normally includes such .gitignore files in its repository, containing patterns for files generated as part of the project build.
And the part about the leading slash is described in the following paragraph:
A leading slash matches the beginning of the pathname. For example, "/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c".
To put it another way, a pattern is normally evaluated as a glob followed by the pattern and will match any path in any subdirectory relative to the location of the .gitignore
file. However if the pattern starts with a slash, it means that the pattern matches exactly from the beginning of the relative pathname.