user-manual: edit "ignoring files" for conciseness
The immediate motivation for writing this section was to explain the
various places ignore patterns could be used. However, I still think
.gitignore is the case most people will want to learn about first. It
also makes it a bit more concrete to introduce ignore patterns in the
context of .gitignore first. And the existance of gitignore(5) relieves
the pressure to explain it all here.
So, stick to the .gitignore example, with only a brief mention of the
others, explain the syntax only by example, and leave the rest to
gitignore(5).
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Cc: Johan Herland <johan@herland.net>
maint
J. Bruce Fields18 years agocommitted byJ. Bruce Fields
@ -1100,20 +1100,14 @@ backup files made by your editor. Of course, 'not' tracking files with git
@@ -1100,20 +1100,14 @@ backup files made by your editor. Of course, 'not' tracking files with git
is just a matter of 'not' calling "`git add`" on them. But it quickly becomes
annoying to have these untracked files lying around; e.g. they make
"`git add .`" and "`git commit -a`" practically useless, and they keep
showing up in the output of "`git status`", etc.
showing up in the output of "`git status`".
Git therefore provides "exclude patterns" for telling git which files to
actively ignore. Exclude patterns are thoroughly explained in the
gitlink:gitignore[5] manual page, but the heart of the concept is simply
a list of files which git should ignore. Entries in the list may contain
globs to specify multiple files, or may be prefixed by "`!`" to
explicitly include (un-ignore) a previously excluded (ignored) file
(i.e. later exclude patterns override earlier ones). The following
example should illustrate such patterns:
You can tell git to ignore certain files by creating a file called .gitignore
in the top level of your working directory, with contents such as:
-------------------------------------------------
# Lines starting with '#' are considered comments.