undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

pathspec: move doc to pathspec.h

Browse Source 
Move the documentation from Documentation/technical/api-setup.txt
to pathspec.h as it's easier for the developers to find the usage
information beside the code instead of looking for it in another doc file.

Also documentation/technical/api-setup.txt is removed because the
information it has is now redundant and it'll be hard to keep it up to
date and synchronized with the documentation in the header file.

Signed-off-by: Heba Waly <heba.waly@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Heba Waly 2019-11-17 21:04:49 +00:00 committed by Junio C Hamano
parent 301d595e72
commit 19ef3ddd36
2 changed files with 34 additions and 48 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
Documentation/technical/api-setup.txt
View File

@ -1,47 +0,0 @@
setup API
=========
Talk about
* setup_git_directory()
* setup_git_directory_gently()
* is_inside_git_dir()
* is_inside_work_tree()
* setup_work_tree()
(Dscho)
Pathspec
--------
See glossary-context.txt for the syntax of pathspec. In memory, a
pathspec set is represented by "struct pathspec" and is prepared by
parse_pathspec(). This function takes several arguments:
- magic_mask specifies what features that are NOT supported by the
following code. If a user attempts to use such a feature,
parse_pathspec() can reject it early.
- flags specifies other things that the caller wants parse_pathspec to
perform.
- prefix and args come from cmd_* functions
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
help.

35
pathspec.h
View File

@ -22,6 +22,11 @@ struct index_state;
#define PATHSPEC_ONESTAR 1 /* the pathspec pattern satisfies GFNM_ONESTAR */
/**
* See glossary-context.txt for the syntax of pathspec.
* In memory, a pathspec set is represented by "struct pathspec" and is
* prepared by parse_pathspec().
*/
struct pathspec {
int nr;
unsigned int has_wildcard:1;
@ -73,18 +78,46 @@ struct pathspec {
*/
#define PATHSPEC_LITERAL_PATH (1<<6)
/*
/**
* Given command line arguments and a prefix, convert the input to
* pathspec. die() if any magic in magic_mask is used.
*
* Any arguments used are copied. It is safe for the caller to modify
* or free 'prefix' and 'args' after calling this function.
*
* - magic_mask specifies what features that are NOT supported by the following
* code. If a user attempts to use such a feature, parse_pathspec() can reject
* it early.
*
* - flags specifies other things that the caller wants parse_pathspec to
* perform.
*
* - prefix and args come from cmd_* functions
*
* 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 help.
*/
void parse_pathspec(struct pathspec *pathspec,
unsigned magic_mask,
unsigned flags,
const char *prefix,
const char **args);
void copy_pathspec(struct pathspec *dst, const struct pathspec *src);
void clear_pathspec(struct pathspec *);