git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH v4 04/11] dir.c: improve docs for match_pathspec() and match_pathspec_depth()

From
Adam Spiers <git@adamspiers.org>
Date
Jan 6, 2013, 16:58 UTC
Message-ID
<1357491493-11619-5-git-send-email-git@adamspiers.org>
In-Reply-To
<1357491493-11619-1-git-send-email-git@adamspiers.org>

Fix a grammatical issue in the description of these functions, and make it more obvious how and why seen[] can be reused across multiple invocations.

Signed-off-by: Adam Spiers <git@adamspiers.org>
---
 dir.c | 38 ++++++++++++++++++++++++++------------
 dir.h |  6 ++++++
 2 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/dir.c b/dir.c
index 46f362e..547b83f 100644
--- a/dir.c
+++ b/dir.c
@@ -167,12 +167,19 @@ static int match_one(const char *match, const char *name, int namelen)
 }
 
 /*
- * Given a name and a list of pathspecs, see if the name matches
- * any of the pathspecs.  The caller is also interested in seeing
- * all pathspec matches some names it calls this function with
- * (otherwise the user could have mistyped the unmatched pathspec),
- * and a mark is left in seen[] array for pathspec element that
- * actually matched anything.
+ * Given a name and a list of pathspecs, returns the nature of the
+ * closest (i.e. most specific) match of the name to any of the
+ * pathspecs.
+ *
+ * The caller typically calls this multiple times with the same
+ * pathspec and seen[] array but with different name/namelen
+ * (e.g. entries from the index) and is interested in seeing if and
+ * how each pathspec matches all the names it calls this function
+ * with.  A mark is left in the seen[] array for each pathspec element
+ * indicating the closest type of match that element achieved, so if
+ * seen[n] remains zero after multiple invocations, that means the nth
+ * pathspec did not match any names, which could indicate that the
+ * user mistyped the nth pathspec.
  */
 int match_pathspec(const char **pathspec, const char *name, int namelen,
 		int prefix, char *seen)
@@ -239,12 +246,19 @@ static int match_pathspec_item(const struct pathspec_item *item, int prefix,
 }
 
 /*
- * Given a name and a list of pathspecs, see if the name matches
- * any of the pathspecs.  The caller is also interested in seeing
- * all pathspec matches some names it calls this function with
- * (otherwise the user could have mistyped the unmatched pathspec),
- * and a mark is left in seen[] array for pathspec element that
- * actually matched anything.
+ * Given a name and a list of pathspecs, returns the nature of the
+ * closest (i.e. most specific) match of the name to any of the
+ * pathspecs.
+ *
+ * The caller typically calls this multiple times with the same
+ * pathspec and seen[] array but with different name/namelen
+ * (e.g. entries from the index) and is interested in seeing if and
+ * how each pathspec matches all the names it calls this function
+ * with.  A mark is left in the seen[] array for each pathspec element
+ * indicating the closest type of match that element achieved, so if
+ * seen[n] remains zero after multiple invocations, that means the nth
+ * pathspec did not match any names, which could indicate that the
+ * user mistyped the nth pathspec.
  */
 int match_pathspec_depth(const struct pathspec *ps,
 			 const char *name, int namelen,
diff --git a/dir.h b/dir.h
index dd42a3a..136e838 100644
--- a/dir.h
+++ b/dir.h
@@ -116,6 +116,12 @@ struct dir_struct {
 	char basebuf[PATH_MAX];
 };
 
+/*
+ * The ordering of these constants is significant, with
+ * higher-numbered match types signifying "closer" (i.e. more
+ * specific) matches which will override lower-numbered match types
+ * when populating the seen[] array.
+ */
 #define MATCHED_RECURSIVELY 1
 #define MATCHED_FNMATCH 2
 #define MATCHED_EXACTLY 3
-- 
1.7.11.7.33.gb8feba5
Previous: Adam SpiersNext: Adam Spiers
Message 9 of 16 in “What's cooking in git.git (Jan 2013, #02; Thu, 3)”
  1. Junio C HamanoJan 3, 2013
  2. Adam SpiersJan 4, 2013
  3. Junio C HamanoJan 4, 2013
  4. Adam SpiersJan 6, 2013
  5. 00/11 new git check-ignore sub-commandAdam Spiers, Jan 6, 2013
  6. 01/11 dir.c: use a single struct exclude_list per source of excludesAdam Spiers, Jan 6, 2013
  7. 02/11 dir.c: keep track of where patterns came fromAdam Spiers, Jan 6, 2013
  8. 03/11 dir.c: provide clear_directory() for reclaiming dir_struct memoryAdam Spiers, Jan 6, 2013
  9. 04/11 dir.c: improve docs for match_pathspec() and match_pathspec_depth()Adam Spiers, Jan 6, 2013
  10. 05/11 add.c: remove unused argument from validate_pathspec()Adam Spiers, Jan 6, 2013
  11. 06/11 add.c: move pathspec matchers into new pathspec.c for reuseAdam Spiers, Jan 6, 2013
  12. 07/11 pathspec.c: rename newly public functions for clarityAdam Spiers, Jan 6, 2013
  13. 08/11 add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuseAdam Spiers, Jan 6, 2013
  14. 09/11 add.c: extract new die_if_path_beyond_symlink() for reuseAdam Spiers, Jan 6, 2013
  15. 10/11 setup.c: document get_pathspec()Adam Spiers, Jan 6, 2013
  16. 11/11 add git-check-ignore sub-commandAdam Spiers, Jan 6, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.