summaryrefslogtreecommitdiff
path: root/builtin/check-ignore.c
AgeCommit message (Collapse)AuthorFilesLines
2013-09-04Merge branch 'sb/parseopt-boolean-removal'Libravatar Junio C Hamano1-6/+6
Convert most uses of OPT_BOOLEAN/OPTION_BOOLEAN that can use OPT_BOOL/OPTION_BOOLEAN which have much saner semantics, and turn remaining ones into OPT_SET_INT, OPT_COUNTUP, etc. as necessary. * sb/parseopt-boolean-removal: revert: use the OPT_CMDMODE for parsing, reducing code checkout-index: fix negations of even numbers of -n config parsing options: allow one flag multiple times hash-object: replace stdin parsing OPT_BOOLEAN by OPT_COUNTUP branch, commit, name-rev: ease up boolean conditions checkout: remove superfluous local variable log, format-patch: parsing uses OPT__QUIET Replace deprecated OPT_BOOLEAN by OPT_BOOL Remove deprecated OPTION_BOOLEAN for parsing arguments
2013-09-04Merge branch 'jc/check-x-z'Libravatar Junio C Hamano1-6/+6
"git check-ignore -z" applied the NUL termination to both its input (with --stdin) and its output, but "git check-attr -z" ignored the option on the output side. This is potentially a backward incompatible fix. Let's see if anybody screams before deciding if we want to do anything to help existing users (there may be none). * jc/check-x-z: check-attr -z: a single -z should apply to both input and output check-ignore -z: a single -z should apply to both input and output check-attr: the name of the character is NUL, not NULL check-ignore: the name of the character is NUL, not NULL
2013-08-05Replace deprecated OPT_BOOLEAN by OPT_BOOLLibravatar Stefan Beller1-6/+6
This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN, 2011-09-27). All occurrences of the respective variables have been reviewed and none of them relied on the counting up mechanism, but all of them were using the variable as a true boolean. This patch does not change semantics of any command intentionally. Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-11check-ignore -z: a single -z should apply to both input and outputLibravatar Junio C Hamano1-1/+1
Unless a command has separate --nul-terminated-{input,output} options, the --nul-terminated-records (-z) option should apply to both input and output for consistency. The caller knows that its input paths may need to be protected for LF, and the program shows these problematic paths to its output. The code already did the right thing. Only the help text needs fixing. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-11check-ignore: the name of the character is NUL, not NULLLibravatar Junio C Hamano1-6/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29Merge branch 'as/check-ignore'Libravatar Junio C Hamano1-42/+50
Enhance "check-ignore" (1.8.2 update) to work more like "check-attr" over bidi-pipes. * as/check-ignore: t0008: use named pipe (FIFO) to test check-ignore streaming Documentation: add caveats about I/O buffering for check-{attr,ignore} check-ignore: allow incremental streaming of queries via --stdin check-ignore: move setup into cmd_check_ignore() check-ignore: add -n / --non-matching option t0008: remove duplicated test fixture data
2013-04-15dir.c: git-status --ignored: don't scan the work tree twiceLibravatar Karsten Blees1-1/+0
'git-status --ignored' still scans the work tree twice to collect untracked and ignored files, respectively. fill_directory / read_directory already supports collecting untracked and ignored files in a single directory scan. However, the DIR_COLLECT_IGNORED flag to enable this has some git-add specific side-effects (e.g. it doesn't recurse into ignored directories, so listing ignored files with --untracked=all doesn't work). The DIR_SHOW_IGNORED flag doesn't list untracked files and returns ignored files in dir_struct.entries[] (instead of dir_struct.ignored[] as DIR_COLLECT_IGNORED). DIR_SHOW_IGNORED is used all throughout git. We don't want to break the existing API, so lets introduce a new flag DIR_SHOW_IGNORED_TOO that lists untracked as well as ignored files similar to DIR_COLLECT_FILES, but will recurse into sub-directories based on the other flags as DIR_SHOW_IGNORED does. In dir.c::read_directory_recursive, add ignored files to either dir_struct.entries[] or dir_struct.ignored[] based on the flags. Also move the DIR_COLLECT_IGNORED case here so that filling result lists is in a common place. In wt-status.c::wt_status_collect_untracked, use the new flag and read results from dir_struct.ignored[]. Remove the extra fill_directory call. builtin/check-ignore.c doesn't call fill_directory, setting the git-add specific DIR_COLLECT_IGNORED flag has no effect here. Remove for clarity. Update API documentation to reflect the changes. Performance: with this patch, 'git-status --ignored' is typically as fast as 'git-status'. Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15dir.c: replace is_path_excluded with now equivalent is_excluded APILibravatar Karsten Blees1-5/+1
Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11check-ignore: allow incremental streaming of queries via --stdinLibravatar Adam Spiers1-10/+5
Some callers, such as the git-annex web assistant, find it useful to invoke git check-ignore as a persistent background process, which can then have queries fed to its STDIN at any point, and the corresponding response consumed from its STDOUT. For this we need to invoke check_ignore() once per line of standard input, and flush standard output after each result. The above use case suggests that empty STDIN is actually a reasonable scenario (e.g. when the caller doesn't know in advance whether any queries need to be fed to the background process until after it's already started), so we make the minor behavioural change that "no pathspec given." is no longer emitted in when STDIN is empty. Even though check_ignore() could now be changed to operate on a single pathspec, we keep it operating on an array of pathspecs since that is a more convenient way of consuming the existing pathspec API. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11check-ignore: move setup into cmd_check_ignore()Libravatar Adam Spiers1-20/+21
Initialisation of the dir_struct and path_exclude_check structs was previously done within check_ignore(). This was acceptable since check_ignore() was only called once per check-ignore invocation; however the next commit will convert it into an inner loop which is called once per line of STDIN when --stdin is given. Therefore moving the initialisation code out into cmd_check_ignore() ensures that initialisation is still only performed once per check-ignore invocation, and consequently that the output is identical whether pathspecs are provided as CLI arguments or via STDIN. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11check-ignore: add -n / --non-matching optionLibravatar Adam Spiers1-17/+29
If `-n` or `--non-matching` are specified, non-matching pathnames will also be output, in which case all fields in each output record except for <pathname> will be empty. This can be useful when running check-ignore as a background process, so that files can be incrementally streamed to STDIN, and for each of these files, STDOUT will indicate whether that file matched a pattern or not. (Without this option, it would be impossible to tell whether the absence of output for a given file meant that it didn't match any pattern, or that the result simply hadn't been flushed to STDOUT yet.) Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19name-hash: allow hashing an empty stringLibravatar Junio C Hamano1-1/+1
Usually we do not pass an empty string to the function hash_name() because we almost always ask for hash values for a path that is a candidate to be added to the index. However, check-ignore (and most likely check-attr, but I didn't check) apparently has a callchain to ask the hash value for an empty path when it was given a "." from the top-level directory to ask "Is the path . excluded by default?" Make sure that hash_name() does not overrun the end of the given pathname even when it is empty. Remove a sweep-the-issue-under-the-rug conditional in check-ignore that avoided to pass an empty string to the callchain while at it. It is a valid question to ask for check-ignore if the top-level is set to be ignored by default, even though the answer is most likely no, if only because there is currently no way to specify such an entry in the .gitignore file. But it is an unusual thing to ask and it is not worth optimizing for it by special casing at the top level of the call chain. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-06add git-check-ignore sub-commandLibravatar Adam Spiers1-0/+173
This works in a similar manner to git-check-attr. Thanks to Jeff King and Junio C Hamano for the idea: http://thread.gmane.org/gmane.comp.version-control.git/108671/focus=108815 Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>