[PATCH] check-ignore: Add option to ignore index contents

check-ignore currently shows how .gitignore rules would treat untracked
paths. Tracked paths do not generate useful output.  This prevents
debugging of why a path became tracked unexpectedly unless that path is
first removed from the index with git rm --cached <path>

This option (-i, --ignore-index) simply by-passes the check for the path
being in the index and hence allows tracked path to be checked too.

Whilst this behaviour deviates from the characteristics of git add and
git status its use case is unlikely to cause any user confusion.

Signed-off-by: Dave Williams <redacted>
---
 Documentation/git-check-ignore.txt |  6 ++++++
 builtin/check-ignore.c             | 10 +++++++---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt
index d2df487..bb878ff 100644
--- a/Documentation/git-check-ignore.txt
+++ b/Documentation/git-check-ignore.txt

@@ -45,6 +45,12 @@ OPTIONS
 	not be possible to distinguish between paths which match a
 	pattern and those which don't.
 
+-i, --ignore-index::
+	Don't look in the index when undertaking the checks. This means
+	the results deviate from those seen by git add and git status
+	but is useful when understanding why a path became tracked by
+	e.g. git add . and was not ignored as expected by the rules.
+
 OUTPUT
 ------
 

diff --git a/builtin/check-ignore.c b/builtin/check-ignore.c
index 4a8fc70..c8f6ae1 100644
--- a/builtin/check-ignore.c
+++ b/builtin/check-ignore.c

@@ -5,7 +5,7 @@
 #include "pathspec.h"
 #include "parse-options.h"
 
-static int quiet, verbose, stdin_paths, show_non_matching;
+static int quiet, verbose, stdin_paths, show_non_matching, ignore_index;
 static const char * const check_ignore_usage[] = {
 "git check-ignore [options] pathname...",
 "git check-ignore [options] --stdin < <list-of-paths>",

@@ -24,6 +24,8 @@ static const struct option check_ignore_options[] = {
 		    N_("input paths are terminated by a null character")),
 	OPT_BOOLEAN('n', "non-matching", &show_non_matching,
 		    N_("show non-matching input paths")),
+	OPT_BOOLEAN('i', "ignore-index", &ignore_index,
+		    N_("ignore index when checking")),
 	OPT_END()
 };
 

@@ -82,7 +84,9 @@ static int check_ignore(struct dir_struct *dir,
 	 * should not be ignored, in order to be consistent with
 	 * 'git status', 'git add' etc.
 	 */
-	seen = find_pathspecs_matching_against_index(pathspec);
+	if (!ignore_index) {
+		seen = find_pathspecs_matching_against_index(pathspec);
+	}
 	for (i = 0; pathspec[i]; i++) {
 		path = pathspec[i];
 		full_path = prefix_path(prefix, prefix

@@ -90,7 +94,7 @@ static int check_ignore(struct dir_struct *dir,
 		full_path = check_path_for_gitlink(full_path);
 		die_if_path_beyond_symlink(full_path, prefix);
 		exclude = NULL;
-		if (!seen[i]) {
+		if (ignore_index || !seen[i]) {
 			exclude = last_exclude_matching(dir, full_path, &dtype);
 		}
 		if (!quiet && (exclude || show_non_matching))

-- 
1.8.4.rc3

On Thu, Aug 29, 2013 at 11:46:52PM +0100, Dave Williams wrote:

check-ignore currently shows how .gitignore rules would treat untracked
paths. Tracked paths do not generate useful output.  This prevents
debugging of why a path became tracked unexpectedly unless that path is
first removed from the index with git rm --cached <path>

This option (-i, --ignore-index) simply by-passes the check for the path
being in the index and hence allows tracked path to be checked too.

Whilst this behaviour deviates from the characteristics of git add and
git status its use case is unlikely to cause any user confusion.

Signed-off-by: Dave Williams <redacted>

[snipped]

Sounds like a great idea to me, and the code changes look reasonable;
however you forgot to add corresponding tests :-)  Please can you
expand the patch to include them?

But I'm in favour in principle - thanks a lot for working on this!

On Fri, Aug 30, 2013 at 5:46 AM, Dave Williams
[off-list ref] wrote:

check-ignore currently shows how .gitignore rules would treat untracked
paths. Tracked paths do not generate useful output.  This prevents
debugging of why a path became tracked unexpectedly unless that path is
first removed from the index with git rm --cached <path>

This option (-i, --ignore-index) simply by-passes the check for the path
being in the index and hence allows tracked path to be checked too.

Maybe --no-index, already used by git-diff and git-grep.

Whilst this behaviour deviates from the characteristics of git add and
git status its use case is unlikely to cause any user confusion.

-- 
Duy

Am 8/30/2013 0:46, schrieb Dave Williams:

+-i, --ignore-index::
+	Don't look in the index when undertaking the checks. This means
+	the results deviate from those seen by git add and git status
+	but is useful when understanding why a path became tracked by
+	e.g. git add . and was not ignored as expected by the rules.

Did you mean to say "was not ignored as expected by the user"? Because the
"the rules" cannot "expect" something, they only "are applied".

-- Hannes