guard against new pathspec magic in pathspec matching code

GUARD_PATHSPEC() marks pathspec-sensitive code, basically all those
that touch anything in 'struct pathspec' except fields "nr" and
"original". GUARD_PATHSPEC() is not supposed to fail. It's mainly to
help the designers catch unsupported codepaths.

Signed-off-by: Nguyễn Thái Ngọc Duy <>
Signed-off-by: Junio C Hamano <>
Nguyễn Thái Ngọc Duy 9 years ago committed by Junio C Hamano
parent dad2586a6b
commit 8f4f8f4579
  1. 19
  2. 2
  3. 2
  4. 7
  5. 19
  6. 2

@ -28,3 +28,22 @@ parse_pathspec(). This function takes several arguments:
- prefix and args come from cmd_* functions
get_pathspec() is obsolete and should never be used in new code.
parse_pathspec() helps catch unsupported features and reject them
politely. At a lower level, different pathspec-related functions may
not support the same set of features. Such pathspec-sensitive
functions are guarded with GUARD_PATHSPEC(), which will die in an
unfriendly way when an unsupported feature is requested.
The command designers are supposed to make sure that GUARD_PATHSPEC()
never dies. They have to make sure all unsupported features are caught
by parse_pathspec(), not by GUARD_PATHSPEC. grepping GUARD_PATHSPEC()
should give the designers all pathspec-sensitive codepaths and what
features they support.
A similar process is applied when a new pathspec magic is added. The
designer lifts the GUARD_PATHSPEC restriction in the functions that
support the new magic. At the same time (s)he has to make sure this
new feature will be caught at parse_pathspec() in commands that cannot
handle the new magic in some cases. grepping parse_pathspec() should

@ -367,6 +367,8 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
if ( {
/* builtin_diff_b_f() */
if (!path)
path = rev.prune_data.items[0].match;
paths +=;

@ -340,6 +340,8 @@ int match_pathspec_depth(const struct pathspec *ps,
int i, retval = 0;
if (!ps->nr) {
if (!ps->recursive ||
!(ps->magic & PATHSPEC_MAXDEPTH) ||

@ -27,6 +27,13 @@ struct pathspec {
} *items;
#define GUARD_PATHSPEC(ps, mask) \
do { \
if ((ps)->magic & ~(mask)) \
die("BUG:%s:%d: unsupported magic %x", \
__FILE__, __LINE__, (ps)->magic & ~(mask)); \
} while (0)
/* parse_pathspec flags */
#define PATHSPEC_PREFER_CWD (1<<0) /* No args means match cwd */
#define PATHSPEC_PREFER_FULL (1<<1) /* No args means match everything */

@ -198,6 +198,25 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
const char *paths[1];
int i;
* follow-rename code is very specific, we need exactly one
* path. Magic that matches more than one path is not
* supported.
#if 0
* We should reject wildcards as well. Unfortunately we
* haven't got a reliable way to detect that 'foo\*bar' in
* fact has no wildcards. nowildcard_len is merely a hint for
* optimization. Let it slip for now until wildmatch is taught
* about dry-run mode and returns wildcard info.
if (opt->pathspec.has_wildcard)
die("BUG:%s:%d: wildcards are not supported",
__FILE__, __LINE__);
/* Remove the file creation entry from the diff queue, and remember it */
choice = q->queue[0];
q->nr = 0;

@ -636,6 +636,8 @@ enum interesting tree_entry_interesting(const struct name_entry *entry,
enum interesting never_interesting = ps->has_wildcard ?
entry_not_interesting : all_entries_not_interesting;
if (!ps->nr) {
if (!ps->recursive ||
!(ps->magic & PATHSPEC_MAXDEPTH) ||