git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "J. Bruce Fields" <bfields@citi.umich.edu>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org,
	"J. Bruce Fields" <bfields@puzzle.fieldses.org>,
	"J. Bruce Fields" <bfields@citi.umich.edu>,
	Johan Herland <johan@herland.net>
Subject: [PATCH 1/6] user-manual: edit "ignoring files" for conciseness
Date: Sun, 26 Aug 2007 12:16:57 -0400	[thread overview]
Message-ID: <30953.9472837516$1188145077@news.gmane.org> (raw)
Message-ID: <464a8a7a15fc70efbcf56c4569f0f7275a9c76fe.1188139206.git.bfields@citi.umich.edu> (raw)
In-Reply-To: <11881450221019-git-send-email->

From: J. Bruce Fields <bfields@puzzle.fieldses.org>

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>
---
 Documentation/user-manual.txt |   63 +++++++++++-----------------------------
 1 files changed, 18 insertions(+), 45 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d6caff4..0331bad 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -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.
-# Ignore foo.txt.
+# Ignore any file named foo.txt.
 foo.txt
 # Ignore (generated) html files,
 *.html
@@ -1123,41 +1117,20 @@ foo.txt
 *.[oa]
 -------------------------------------------------
 
-The next question is where to put these exclude patterns so that git can
-find them. Git looks for exclude patterns in the following files:
-
-`.gitignore` files in your working tree:::
-	   You may store multiple `.gitignore` files at various locations in your
-	   working tree. Each `.gitignore` file is applied to the directory where
-	   it's located, including its subdirectories. Furthermore, the
-	   `.gitignore` files can be tracked like any other files in your working
-	   tree; just do a "`git add .gitignore`" and commit. `.gitignore` is
-	   therefore the right place to put exclude patterns that are meant to
-	   be shared between all project participants, such as build output files
-	   (e.g. `\*.o`), etc.
-`.git/info/exclude` in your repo:::
-	   Exclude patterns in this file are applied to the working tree as a
-	   whole. Since the file is not located in your working tree, it does
-	   not follow push/pull/clone like `.gitignore` can do. This is therefore
-	   the place to put exclude patterns that are local to your copy of the
-	   repo (i.e. 'not' shared between project participants), such as
-	   temporary backup files made by your editor (e.g. `\*~`), etc.
-The file specified by the `core.excludesfile` config directive:::
-	   By setting the `core.excludesfile` config directive you can tell git
-	   where to find more exclude patterns (see gitlink:git-config[1] for
-	   more information on configuration options). This config directive
-	   can be set in the per-repo `.git/config` file, in which case the
-	   exclude patterns will apply to that repo only. Alternatively, you
-	   can set the directive in the global `~/.gitconfig` file to apply
-	   the exclude pattern to all your git repos. As with the above
-	   `.git/info/exclude` (and, indeed, with git config directives in
-	   general), this directive does not follow push/pull/clone, but remain
-	   local to your repo(s).
-
-[NOTE]
-In addition to the above alternatives, there are git commands that can take
-exclude patterns directly on the command line. See gitlink:git-ls-files[1]
-for an example of this.
+See gitlink:gitignore[5] for a detailed explanation of the syntax.  You can
+also place .gitignore files in other directories in your working tree, and they
+will apply to those directories and their subdirectories.  The `.gitignore`
+files can be added to your repository like any other files (just run `git add
+.gitignore` and `git commit`, as usual), which is convenient when the exclude
+patterns (such as patterns matching build output files) would also make sense
+for other users who clone your repository.
+
+If you wish the exclude patterns to affect only certain repositories
+(instead of every repository for a given project), you may instead put
+them in a file in your repository named .git/info/exclude, or in any file
+specified by the `core.excludesfile` configuration variable.  Some git
+commands can also take exclude patterns directly on the command line.
+See gitlink:gitignore[5] for the details.
 
 [[how-to-merge]]
 How to merge
-- 
1.5.3.rc5.19.g0734d

       reply	other threads:[~2007-08-26 16:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <11881450221019-git-send-email->
     [not found] ` <464a8a7a15fc70efbcf56c4569f0f7275a9c76fe.1188139206.git.bfields@citi.umich.edu>
2007-08-26 16:16   ` J. Bruce Fields [this message]
     [not found]   ` <a5f90f31302eb47cb1aa2f12447376ff9332abef.1188139206.git.bfields@citi.umich.edu>
2007-08-26 16:16     ` [PATCH 2/6] user-manual: minor editing for conciseness J. Bruce Fields
     [not found]   ` <a2ef9d633f67edc227b00209d5b72ec388388877.1188139206.git.bfields@citi.umich.edu>
2007-08-26 16:16     ` [PATCH 3/6] user-manual: introduce the word "commit" earlier J. Bruce Fields
     [not found]   ` <e2618ff42716dd7cbc7a353670f46f357c5fb4c5.1188139206.git.bfields@citi.umich.edu>
2007-08-26 16:17     ` [PATCH 4/6] user-manual: use pithier example commit J. Bruce Fields
     [not found]   ` <d5821de2e29a3a207a2c5188f73b7d1f6d52fc34.1188139206.git.bfields@citi.umich.edu>
2007-08-26 16:17     ` [PATCH 5/6] user-manual: fix incorrect header level J. Bruce Fields
     [not found]   ` <a115daff12d8d26975ff15a4278a212df2c8c70b.1188139206.git.bfields@citi.umich.edu>
2007-08-26 16:17     ` [PATCH 6/6] Documentation/user-manual.txt: fix a few omissions of gitlink commands J. Bruce Fields
     [not found] ` <11881450231606-git-send-email->
     [not found]   ` <11881450231010-git-send-email->
     [not found]     ` <11881450233251-git-send-email->
     [not found]       ` <11881450231946-git-send-email->
2007-08-26 19:57   ` [PATCH 1/6] user-manual: edit "ignoring files" for conciseness Johan Herland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='30953.9472837516$1188145077@news.gmane.org' \
    --to=bfields@citi.umich.edu \
    --cc=bfields@puzzle.fieldses.org \
    --cc=git@vger.kernel.org \
    --cc=johan@herland.net \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).