summaryrefslogtreecommitdiff
path: root/builtin/check-attr.c
AgeCommit message (Collapse)Author
2016-01-15check-attr: there are only two possible line terminationsJunio C Hamano
The program by default reads LF terminated lines, with an option to use NUL terminated records. Instead of pretending that there can be other useful values for line_termination, use a boolean variable, nul_term_line, to tell if NUL terminated records are used, and switch between strbuf_getline_{lf,nul} based on it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16usage: do not insist that standard input must come from a fileJunio C Hamano
The synopsys text and the usage string of subcommands that read list of things from the standard input are often shown like this: git gostak [--distim] < <list-of-doshes> This is problematic in a number of ways: * The way to use these commands is more often to feed them the output from another command, not feed them from a file. * Manual pages outside Git, commands that operate on the data read from the standard input, e.g "sort", "grep", "sed", etc., are not described with such a "< redirection-from-file" in their synopsys text. Our doing so introduces inconsistency. * We do not insist on where the output should go, by saying git gostak [--distim] < <list-of-doshes> > <output> * As it is our convention to enclose placeholders inside <braket>, the redirection operator followed by a placeholder filename becomes very hard to read, both in the documentation and in the help text. Let's clean them all up, after making sure that the documentation clearly describes the modes that take information from the standard input and what kind of things are expected on the input. [jc: stole example for fmt-merge-msg from Jonathan] Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-14standardize usage info string formatAlex Henrie
This patch puts the usage info strings that were not already in docopt- like format into docopt-like format, which will be a litle easier for end users and a lot easier for translators. Changes include: - Placing angle brackets around fill-in-the-blank parameters - Putting dashes in multiword parameter names - Adding spaces to [-f|--foobar] to make [-f | --foobar] - Replacing <foobar>* with [<foobar>...] Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-14Merge branch 'jc/check-attr-honor-working-tree'Junio C Hamano
"git check-attr" when (trying to) work on a repository with a working tree did not work well when the working tree was specified via --work-tree (and obviously with --git-dir). The command also works in a bare repository but it reads from the (possibly stale, irrelevant and/or nonexistent) index, which may need to be fixed to read from HEAD, but that is a completely separate issue. As a related tangent to this separate issue, we may want to also fix "check-ignore", which refuses to work in a bare repository, to also operate in a bare one. * jc/check-attr-honor-working-tree: check-attr: move to the top of working tree when in non-bare repository t0003: do not chdir the whole test process
2014-02-06check-attr: move to the top of working tree when in non-bare repositoryJunio C Hamano
Lasse Makholm noticed that running "git check-attr" from a place totally unrelated to $GIT_DIR and $GIT_WORK_TREE does not give expected results. I think it is because the command does not say it wants to call setup_work_tree(). We still need to support use cases where only a bare repository is involved, so unconditionally requiring a working tree would not work well. Instead, make a call only in a non-bare repository. We may want to see if we want to do a similar fix in the opposite direction to check-ignore. The command unconditionally requires a working tree, but it should be usable in a bare repository just like check-attr attempts to be. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-04Merge branch 'sb/parseopt-boolean-removal'Junio C Hamano
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-08-05Replace deprecated OPT_BOOLEAN by OPT_BOOLStefan Beller
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-12check-attr -z: a single -z should apply to both input and outputJunio C Hamano
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. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-12check-attr: the name of the character is NUL, not NULLJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17Merge branch 'maint'Junio C Hamano
* maint: t/perf: add "trash directory" to .gitignore Add missing -z to git check-attr usage text for consistency with man page git-jump: ignore (custom) prefix in diff mode Documentation: indent-with-non-tab uses "equivalent tabs" not 8 completion: add --no-edit to git-commit
2012-09-17Add missing -z to git check-attr usage text for consistency with man pageAdam Spiers
Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-20i18n: check-attr: mark parseopt strings for translationNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-18Merge branch 'bc/attr-ignore-case'Junio C Hamano
* bc/attr-ignore-case: attr.c: respect core.ignorecase when matching attribute patterns attr: read core.attributesfile from git_default_core_config builtin/mv.c: plug miniscule memory leak cleanup: use internal memory allocation wrapper functions everywhere attr.c: avoid inappropriate access to strbuf "buf" member Conflicts: transport-helper.c
2011-10-06attr: read core.attributesfile from git_default_core_configJunio C Hamano
This code calls git_config from a helper function to parse the config entry it is interested in. Calling git_config in this way may cause a problem if the helper function can be called after a previous call to git_config by another function since the second call to git_config may reset some variable to the value in the config file which was previously overridden. The above is not a problem in this case since the function passed to git_config only parses one config entry and the variable it sets is not assigned outside of the parsing function. But a programmer who desires all of the standard config options to be parsed may be tempted to modify git_attr_config() so that it falls back to git_default_config() and then it _would_ be vulnerable to the above described behavior. So, move the call to git_config up into the top-level cmd_* function and move the responsibility for parsing core.attributesfile into the main config file parser. Which is only the logical thing to do ;-) Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-22Teach '--cached' option to check-attrJay Soffian
This option causes check-attr to consider .gitattributes only from the index, ignoring .gitattributes from the working tree. This allows the command to be used in situations where a working tree does not exist. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Normalize pathsMichael Haggerty
Normalize the path arguments (relative to the working tree root, if applicable) before looking up their attributes. This requires passing the prefix down the call chain. This fixes two test cases for different reasons: * "unnormalized paths" is fixed because the .gitattribute-file-seeking code is not confused into reading the top-level file twice. * "relative paths" is fixed because the canonical pathnames are passed to get_check_attr() or get_all_attrs(), allowing them to match the pathname patterns as expected. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04Rename git_checkattr() to git_check_attr()Michael Haggerty
Suggested by: Junio Hamano <gitster@pobox.com> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Fix command-line handling to match docsMichael Haggerty
According to the git-check-attr synopsis, if the '--stdin' option is used then no pathnames are expected on the command line. Change the behavior to match this description; namely, if '--stdin' is used but not '--', then treat all command-line arguments as attribute names. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Add an --all option to show all attributesMichael Haggerty
Add new usage patterns git check-attr [-a | --all] [--] pathname... git check-attr --stdin [-a | --all] < <list-of-paths> which display all attributes associated with the specified file(s). Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Error out if no pathnames are specifiedMichael Haggerty
If no pathnames are passed as command-line arguments and the --stdin option is not specified, fail with the error message "No file specified". Add tests of this behavior. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Process command-line args more systematicallyMichael Haggerty
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Handle each error separatelyMichael Haggerty
This will make the code easier to refactor. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Extract a function error_with_usage()Michael Haggerty
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Introduce a new variableMichael Haggerty
Avoid reusing variable "doubledash" to mean something other than the expected "position of a double-dash, if any". Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Extract a function output_attr()Michael Haggerty
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Use git_attr_name()Michael Haggerty
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLinus Torvalds
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>