path: root/Documentation/git-check-attr.txt
AgeCommit message (Collapse)Author
2019-11-07Documentation: fix a bunch of typos, both old and newElijah Newren
Reported-by: Jens Schleusener <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2018-05-25Use proper syntax for replaceables in command docsRobert P. J. Day
The standard for command documentation synopses appears to be: [...] means optional <...> means replaceable [<...>] means both optional and replaceable So fix a number of doc pages that use incorrect variations of the above. Signed-off-by: Robert P. J. Day <> Signed-off-by: Junio C Hamano <>
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 <> Signed-off-by: Junio C Hamano <>
2013-09-04Merge branch 'jc/check-x-z'Junio C Hamano
"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-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 <>
2013-04-11Documentation: add caveats about I/O buffering for check-{attr,ignore}Adam Spiers
check-attr and check-ignore have the potential to deadlock callers which do not read back the output in real-time. For example, if a caller writes N paths out and then reads N lines back in, it risks becoming blocked on write() to check-*, and check-* is blocked on write back to the caller. Somebody has to buffer; the pipe buffers provide some leeway, but they are limited. Thanks to Peff for pointing this out: Signed-off-by: Adam Spiers <> Signed-off-by: Junio C Hamano <>
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 <> Signed-off-by: Junio C Hamano <>
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 <> Signed-off-by: Junio C Hamano <>
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 <> Signed-off-by: Junio C Hamano <>
2011-03-11doc: drop author/documentation sections from most pagesJeff King
The point of these sections is generally to: 1. Give credit where it is due. 2. Give the reader an idea of where to ask questions or file bug reports. But they don't do a good job of either case. For (1), they are out of date and incomplete. A much more accurate answer can be gotten through shortlog or blame. For (2), the correct contact point is generally git@vger, and even if you wanted to cc the contact point, the out-of-date and incomplete fields mean you're likely sending to somebody useless. So let's drop the fields entirely from all manpages except git(1) itself. We already point people to the mailing list for bug reports there, and we can update the Authors section to give credit to the major contributors and point to shortlog and blame for more information. Each page has a "This is part of git" footer, so people can follow that to the main git manpage.
2009-03-23Documentation: minor grammatical fixes in git-check-attr.txtDavid J. Mellor
Signed-off-by: David J. Mellor <> Signed-off-by: Junio C Hamano <>
2008-11-12Merge branch 'maint'Junio C Hamano
* maint: Start cycle Fix pack.packSizeLimit and --max-pack-size handling checkout: Fix "initial checkout" detection Remove the period after the git-check-attr summary Conflicts: RelNotes
2008-11-12Remove the period after the git-check-attr summaryMatt Kraai
The period at the end of the git-check-attr summary causes there to be two periods after the summary in the git(1) manual page. Signed-off-by: Matt Kraai <> Signed-off-by: Junio C Hamano <>
2008-10-19Merge branch 'dp/checkattr'Junio C Hamano
* dp/checkattr: git-check-attr(1): use 'verse' for multi-line synopsis sections check-attr: Add --stdin option check-attr: add an internal check_attr() function
2008-10-16git-check-attr(1): use 'verse' for multi-line synopsis sectionsJonas Fonseca
Signed-off-by: Jonas Fonseca <> Signed-off-by: Junio C Hamano <>
2008-10-16git-check-attr(1): add output and example sectionsJonas Fonseca
Plumbing tools should document what output can be expected. Signed-off-by: Jonas Fonseca <> Signed-off-by: Junio C Hamano <>
2008-10-12check-attr: Add --stdin optionDmitry Potapov
This allows multiple paths to be specified on stdin. Signed-off-by: Dmitry Potapov <> Signed-off-by: Shawn O. Pearce <>
2008-07-21Update my e-mail addressJunio C Hamano
The old address is still getting mails from gitters. Signed-off-by: Junio C Hamano <>
2008-07-02Documentation: be consistent about "git-" versus "git "Jonathan Nieder
Since the git-* commands are not installed in $(bindir), using "git-command <parameters>" in examples in the documentation is not a good idea. On the other hand, it is nice to be able to refer to each command using one hyphenated word. (There is no escaping it, anyway: man page names cannot have spaces in them.) This patch retains the dash in naming an operation, command, program, process, or action. Complete command lines that can be entered at a shell (i.e., without options omitted) are made to use the dashless form. The changes consist only of replacing some spaces with hyphens and vice versa. After a "s/ /-/g", the unpatched and patched versions are identical. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2008-06-06documentation: move git(7) to git(1)Christian Couder
As the "git" man page describes the "git" command at the end-user level, it seems better to move it to man section 1. Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>
2008-01-07Documentation: rename gitlink macro to linkgitDan McGee
Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock Asciidoc configuration: @@ -149,7 +153,10 @@ # Inline macros. # Backslash prefix required for escape processing. # (?s) re flag for line spanning. -(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + +# Explicit so they can be nested. +(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + # Anchor: [[[id]]]. Bibliographic anchor. (?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3 # Anchor: [[id,xreflabel]] This default regex now matches explicit values, and unfortunately in this case gitlink was being matched by just 'link', causing the wrong inline macro template to be applied. By renaming the macro, we can avoid being matched by the wrong regex. Signed-off-by: Dan McGee <> Signed-off-by: Junio C Hamano <>
2007-12-23Documentation: describe 'union' low-level merge driverJunio C Hamano
Signed-off-by: Junio C Hamano <>
2007-06-07War on whitespaceJunio C Hamano
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <>
2007-04-15Document git-check-attrJames Bowes
Signed-off-by: James Bowes <> Signed-off-by: Junio C Hamano <>