Ack. But I fear this makes the gitignore page feel even more top-heavy than it already is. The current structure is: SYNOPSIS [list of excludes files] DESCRIPTION One-sentence description. Long comment about some totally different command. Description of structure. Long comment about precedence rules: . some rules ... Paragraph about which excludes file works for which use case. Paragraph about which commands pay attention to excludes files. Patterns have the following format: . some rules ... An example: transcript Another example: transcript Quick analysis. DOCUMENTATION Various people's names. GIT Part of the git(1) suite. It's a wonder people can find anything there. :) So how about this? Patch 1 splits the description into three sections. Yes, having the PATTERN FORMAT section is not part of the conventional list in man-pages(7), but I think it's easier to find the interesting part this way. Patch 2 puts the comments about related commands in a separate NOTES section. This way, one could expand on the "stop tracking file" procedure without interrupting the flow of the basic description of what excludes files do, by adding to the NOTES or EXAMPLES section. Thoughts? Jonathan Nieder (2): Documentation: split gitignore page into sections Documentation: point to related commands from gitignore Documentation/gitignore.txt | 30 +++++++++++++++++++++++------- 1 files changed, 23 insertions(+), 7 deletions(-) -- 1.7.2.3.557.gab647.dirty --
A learner-by-example might want to look at the examples section first.
Help her out by supplying some section headings: PATTERN FORMAT for
the format of lines in an excludes file and EXAMPLES for the two
examples.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/gitignore.txt | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 7dc2e8b..254bc1a 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -62,7 +62,8 @@ files specified by command-line options. Higher-level git
tools, such as 'git status' and 'git add',
use patterns from the sources specified above.
-Patterns have the following format:
+PATTERN FORMAT
+--------------
- A blank line matches no files, so it can serve as a separator
for readability.
@@ -98,7 +99,8 @@ Patterns have the following format:
For example, "/{asterisk}.c" matches "cat-file.c" but not
"mozilla-sha1/sha1.c".
-An example:
+EXAMPLES
+--------
--------------------------------------------------------------
$ git status
--
1.7.2.3.557.gab647.dirty
--
A frequently asked question on #git is how to stop tracking a file
that is mistakenly tracked by git. A frequently attempted strategy is
to add such files to .gitignore.
Thus one might imagine that the gitignore documentation could be a
good entry point for 'git rm' documentation. Add some
cross-references in this vein.
While at it, move a reference to update-index --assume-unchanged from
the DESCRIPTION to lower down on the page. This way, the methodical
reader can benefit from first learning what excludes files do, then
how they relate to other git facilities.
Based-on-patch-by: Sitaram Chamarty <sitaram@atc.tcs.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
This NOTES section is a bit of a placeholder. I think it is an
improvement already, but if someone wants to flesh it out I wouldn't
complain.
Hope that helps.
Documentation/gitignore.txt | 24 +++++++++++++++++++-----
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 254bc1a..8416f34 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -14,11 +14,8 @@ DESCRIPTION
A `gitignore` file specifies intentionally untracked files that
git should ignore.
-Note that all the `gitignore` files really concern only files
-that are not already tracked by git;
-in order to ignore uncommitted changes in already tracked files,
-please refer to the 'git update-index --assume-unchanged'
-documentation.
+Files already tracked by git are not affected; see the NOTES
+below for details.
Each line in a `gitignore` file specifies a pattern.
When deciding whether to ignore a path, git normally checks
@@ -99,6 +96,18 @@ PATTERN FORMAT
For example, "/{asterisk}.c" matches "cat-file.c" but not
"mozilla-sha1/sha1.c".
+NOTES
+-----
+
+The purpose of gitignore files is to ensure that certain files
+not tracked by git remain untracked.
+
+To ignore uncommitted changes in a file that is ...I am not very happy with the wording "to do X, use Y" above, though. For example, "rm --cached" is a good starting point, but that needs to be followed by a commit some time in the future to take permanent effect. The realization that "rm --cached" is a good starting point would come only with an understanding of what "rm --cached" does (i.e. it removes the path from the index, preparing for its removal from the future history). "to do X, see Y" might be a good compromise, because what I am suggesting by the above is that ideally to say "to do X means doing Z so using Y is a good way to achieve it", but "... means doing Z" part is explained in the manual page of Y. In any case, will queue. Thanks. --
Oh... I hadn't thought of that. I was looking at "what's the minimum change needed to at least mention 'git rm --cached' somewhere". ++ from me on this approach. regards sitaram --
