dir.c: improve docs for match_pathspec() and match_pathspec_depth()
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
parent
270be81604
commit
52ed1894b0
38
dir.c
38
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,
|
||||
|
6
dir.h
6
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
|
||||
|
Loading…
Reference in New Issue
Block a user