Re: [PATCH 2/2] Documentation: point to related commands from gitignore

Previous thread: is it kosher for pre-commit to change what's staged? by Joey Hess on Wednesday, November 10, 2010 - 10:08 am. (9 messages)

Next thread: Re: Understanding git cherry-pick by Stephen Bash on Wednesday, November 10, 2010 - 1:01 pm. (1 message)
From: Jonathan Nieder
Date: Wednesday, November 10, 2010 - 11:55 am

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

--

From: Jonathan Nieder
Date: Wednesday, November 10, 2010 - 11:57 am

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

--

From: Jonathan Nieder
Date: Wednesday, November 10, 2010 - 12:00 pm

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 ...
From: Junio C Hamano
Date: Thursday, November 11, 2010 - 12:05 pm

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.
--

From: Sitaram Chamarty
Date: Wednesday, November 10, 2010 - 6:10 pm

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
--

Previous thread: is it kosher for pre-commit to change what's staged? by Joey Hess on Wednesday, November 10, 2010 - 10:08 am. (9 messages)

Next thread: Re: Understanding git cherry-pick by Stephen Bash on Wednesday, November 10, 2010 - 1:01 pm. (1 message)