summaryrefslogtreecommitdiff
path: root/Documentation/git-grep.txt
AgeCommit message (Collapse)AuthorFilesLines
2013-10-23Merge branch 'mg/more-textconv'Libravatar Junio C Hamano1-1/+8
Make "git grep" and "git show" pay attention to --textconv when dealing with blob objects. * mg/more-textconv: grep: honor --textconv for the case rev:path grep: allow to use textconv filters t7008: demonstrate behavior of grep with textconv cat-file: do not die on --textconv without textconv filters show: honor --textconv for blobs diff_opt: track whether flags have been set explicitly t4030: demonstrate behavior of show with textconv
2013-05-17documentation: trivial style cleanupsLibravatar Felipe Contreras1-1/+1
White-spaces, missing braces, standardize --[no-]foo. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-10grep: allow to use textconv filtersLibravatar Jeff King1-1/+8
Recently and not so recently, we made sure that log/grep type operations use textconv filters when a userfacing diff would do the same: ef90ab6 (pickaxe: use textconv for -S counting, 2012-10-28) b1c2f57 (diff_grep: use textconv buffers for add/deleted files, 2012-10-28) 0508fe5 (combine-diff: respect textconv attributes, 2011-05-23) "git grep" currently does not use textconv filters at all, that is neither for displaying the match and context nor for the actual grepping, even when requested by --textconv. Introduce an option "--textconv" which makes git grep use any configured textconv filters for grepping and output purposes. It is off by default. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-1/+1
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-03grep: add a grep.patternType configuration settingLibravatar J Smith1-1/+9
The grep.extendedRegexp configuration setting enables the -E flag on grep by default but there are no equivalents for the -G, -F and -P flags. Rather than adding an additional setting for grep.fooRegexp for current and future pattern matching options, add a grep.patternType setting that can accept appropriate values for modifying the default grep pattern matching behavior. The current values are "basic", "extended", "fixed", "perl" and "default" for setting -G, -E, -F, -P and the default behavior respectively. When grep.patternType is set to a value other than "default", the grep.extendedRegexp setting is ignored. The value of "default" restores the current default behavior, including the grep.extendedRegexp behavior. Signed-off-by: J Smith <dark.panda@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-25Merge branch 'rs/maint-grep-F'Libravatar Junio C Hamano1-1/+3
"git grep -e '$pattern'", unlike the case where the patterns are read from a file, did not treat individual lines in the given pattern argument as separate regular expressions as it should.
2012-05-20grep: support newline separated pattern listLibravatar René Scharfe1-1/+3
Currently, patterns that contain newline characters don't match anything when given to git grep. Regular grep(1) interprets patterns as lists of newline separated search strings instead. Implement this functionality by creating and inserting extra grep_pat structures for patterns consisting of multiple lines when appending to the pattern lists. For simplicity, all pattern strings are duplicated. The original pattern is truncated in place to make it contain only the first line. Requested-by: Torne (Richard Coles) <torne@google.com> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-2/+2
In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-26grep doc: add --break / --heading / -W to synopsisLibravatar Mark Lodato1-0/+2
All of the other options were included in the synopsis, so it makes sense to include these as well. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-14Document limited recursion pathspec matching with wildcardsLibravatar Nguyễn Thái Ngọc Duy1-0/+3
It's actually unlimited recursion if wildcards are active regardless --max-depth Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-04Merge branch 'jc/maint-grep-untracked-exclude' into jc/grep-untracked-excludeLibravatar Junio C Hamano1-2/+15
* jc/maint-grep-untracked-exclude: grep: teach --untracked and --exclude-standard options grep --no-index: don't use git standard exclusions grep: do not use --index in the short usage output Conflicts: Documentation/git-grep.txt builtin/grep.c
2011-10-04grep: teach --untracked and --exclude-standard optionsLibravatar Junio C Hamano1-1/+14
In a working tree of a git managed repository, "grep --untracked" would find the specified patterns from files in untracked files in addition to its usual behaviour of finding them in the tracked files. By default, when working with "--no-index" option, "grep" does not pay attention to .gitignore mechanism. "grep --no-index --exclude-standard" can be used to tell the command to use .gitignore and stop reporting hits from files that would be ignored. Also, when working without "--no-index", "grep" honors .gitignore mechanism, and "grep --no-exclude-standard" can be used to tell the command to include hits from files that are ignored. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11Merge branch 'rs/grep-function-context'Libravatar Junio C Hamano1-9/+23
* rs/grep-function-context: grep: long context options grep: add option to show whole function as context
2011-08-04docs: put listed example commands in backticksLibravatar Jeff King1-3/+3
Many examples of git command invocation are given in asciidoc listing blocks, which makes them monospaced and avoids further interpretation of special characters. Some manpages make a list of examples, like: git foo:: Run git foo. git foo -q:: Use the "-q" option. to quickly show many variants. However, they can sometimes be hard to read, because they are shown in a proportional-width font (so, for example, seeing the difference between "-- foo" and "--foo" can be difficult). This patch puts all such examples into backticks, which gives the equivalent formatting to a listing block (i.e., monospaced and without character interpretation). As a bonus, this also fixes an example in the git-push manpage, in which "git push origin :::" was accidentally considered a newly-indented list, and not a list item with "git push origin :" in it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-01grep: long context optionsLibravatar René Scharfe1-9/+17
Take long option names for -A (--after-context), -B (--before-context) and -C (--context) from GNU grep and add a similar long option name for -W (--function-context). Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-01grep: add option to show whole function as contextLibravatar René Scharfe1-0/+6
Add a new option, -W, to show the whole surrounding function of a match. It uses the same regular expressions as -p and diff to find the beginning of sections. Currently it will not display comments in front of a function, but those that are following one. Despite this shortcoming it is already useful, e.g. to simply see a more complete applicable context or to extract whole functions. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-05grep: add --headingLibravatar René Scharfe1-0/+4
With --heading, the filename is printed once before matches from that file instead of at the start of each line, giving more screen space to the actual search results. This option is taken from ack (http://betterthangrep.com/). And now git grep can dress up like it: $ git config alias.ack "grep --break --heading --line-number" $ git ack -e --heading Documentation/git-grep.txt 154:--heading:: t/t7810-grep.sh 785:test_expect_success 'grep --heading' ' 786: git grep --heading -e char -e lo_w hello.c hello_world >actual && 808: git grep --break --heading -n --color \ Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-05grep: add --breakLibravatar René Scharfe1-0/+3
With --break, an empty line is printed between matches from different files, increasing readability. This option is taken from ack (http://betterthangrep.com/). Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-09git-grep: Learn PCRELibravatar Michał Kiedrowicz1-0/+6
This patch teaches git-grep the --perl-regexp/-P options (naming borrowed from GNU grep) in order to allow specifying PCRE regexes on the command line. PCRE has a number of features which make them more handy to use than POSIX regexes, like consistent escaping rules, extended character classes, ungreedy matching etc. git isn't build with PCRE support automatically. USE_LIBPCRE environment variable must be enabled (like `make USE_LIBPCRE=YesPlease`). Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-05Documentation: Add --line-number to git-grep synopsisLibravatar Michał Kiedrowicz1-1/+1
Commit 7d6cb10b ("grep: Add the option '--line-number'", 2011-03-28) introduced the --line-number option and added its description to OPTIONS section, but forgot to update SYNOPSIS. Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30grep: allow -E and -n to be turned on by default via configurationLibravatar Joe Ratterman1-0/+10
Add two configration variables grep.extendedRegexp and grep.lineNumbers to allow the user to skip typing -E and -n on the command line, respectively. Scripts that are meant to be used by random users and/or in random repositories now have use -G and/or --no-line-number options as appropriately to override the settings in the repository or user's ~/.gitconfig settings. Just because the script didn't say "git grep -n" no longer guarantees that the output from the command will not have line numbers. Signed-off-by: Joe Ratterman <jratt0@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-28Merge branch 'maint'Libravatar Junio C Hamano1-0/+1
* maint: git tag documentation grammar fixes and readability updates grep: Add the option '--line-number'
2011-03-28grep: Add the option '--line-number'Libravatar Joe Ratterman1-0/+1
This is a synonym for the existing '-n' option, matching GNU grep. Signed-off-by: Joe Ratterman <jratt0@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-10/+0
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.
2010-08-20Documentation: add missing quotes to "git grep" examplesLibravatar Jonathan Nieder1-2/+2
Without an indication to the contrary, Asciidoc puts 'quoted text' in italics, making the output look like this: git grep time_t -- *.[ch] Looks for time_t in all tracked .c and .h files in the working directory and its subdirectories. git grep -e '#define\' --and \( -e MAX_PATH -e PATH_MAX \) Looks for a line that has #define and either MAX_PATH or PATH_MAX. In the first example, the *.[ch] argument needs to be protected from the shell, or else it will only match files in the current directory. The second example has a stray backslash. Reported-by: Frédéric Brière <fbriere@fbriere.net> Cc: Mark Lodato <lodatom@gmail.com> Cc: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-30Merge branch 'jn/grep-open'Libravatar Junio C Hamano1-0/+8
* jn/grep-open: t/t7811-grep-open.sh: remove broken/redundant creation of fake "less" script t/t7811-grep-open.sh: ensure fake "less" is made executable t/lib-pager.sh: remove unnecessary '^' from 'expr' regular expression grep -O: allow optional argument specifying the pager (or editor) grep: Add the option '--open-files-in-pager' Unify code paths of threaded greps grep: refactor grep_objects loop into its own function Conflicts: t/t7006-pager.sh
2010-06-25Documentation: grep: fix asciidoc problem with --Libravatar Christian Couder1-1/+1
Asciidoc interprets two dashes separated by spaces as a single big dash. So let's escape the first dash, so that "\--" will properly appear as "--". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-13grep -O: allow optional argument specifying the pager (or editor)Libravatar Johannes Schindelin1-3/+3
Suppose you want to edit all files that contain a specific search term. Of course, you can do something totally trivial such as git grep -z -e <term> | xargs -0r vi +/<term> but maybe you are happy that the same will be achieved by git grep -Ovi <term> now. [jn: rebased and added tests] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-13grep: Add the option '--open-files-in-pager'Libravatar Johannes Schindelin1-0/+8
This adds an option to open the matching files in the pager, and if the pager happens to be "less" (or "vi") and there is only one grep pattern, it also jumps to the first match right away. The short option was chose as '-O' to avoid clashes with GNU grep's options (as suggested by Junio). So, 'git grep -O abc' is a short form for 'less +/abc $(grep -l abc)' except that it works also with spaces in file names, and it does not start the pager if there was no matching file. [jn: rebased and added tests; with error handling fix from Junio squashed in] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-07Merge branch 'ml/maint-grep-doc'Libravatar Junio C Hamano1-13/+17
* ml/maint-grep-doc: grep docs: document --no-index option grep docs: --cached and <tree>... are incompatible grep docs: use AsciiDoc literals consistently grep docs: pluralize "Example" section
2010-03-02Merge branch 'ml/color-when'Libravatar Junio C Hamano1-2/+4
* ml/color-when: Add an optional argument for --color options
2010-02-25grep docs: document --no-index optionLibravatar Mark Lodato1-4/+8
Also clarify --cached and <tree>. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-25grep docs: --cached and <tree>... are incompatibleLibravatar Mark Lodato1-3/+3
In the synopsis for git-grep(1), show that --cached and <tree>... cannot be used together. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-25grep docs: use AsciiDoc literals consistentlyLibravatar Mark Lodato1-5/+5
The convention for this particular page is to use AsciiDoc literal strings only for options (`-x` or `--long`), but not for definition list terms and not for <meta-vars>. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-25grep docs: pluralize "Example" sectionLibravatar Mark Lodato1-2/+2
Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24Merge branch 'ml/maint-grep-doc' into maintLibravatar Junio C Hamano1-5/+12
* ml/maint-grep-doc: grep documentation: clarify what files match
2010-02-21Merge branch 'ml/maint-grep-doc'Libravatar Junio C Hamano1-5/+12
* ml/maint-grep-doc: grep documentation: clarify what files match
2010-02-18Add an optional argument for --color optionsLibravatar Mark Lodato1-2/+4
Make git-branch, git-show-branch, git-grep, and all the diff-based programs accept an optional argument <when> for --color. The argument is a colorbool: "always", "never", or "auto". If no argument is given, "always" is used; --no-color is an alias for --color=never. This makes the command-line interface consistent with other GNU tools, such as `ls' and `grep', and with the git-config color options. Note that, without an argument, --color and --no-color work exactly as before. To implement this, two internal changes were made: 1. Allow the first argument of git_config_colorbool() to be NULL, in which case it returns -1 if the argument isn't "always", "never", or "auto". 2. Add OPT_COLOR_FLAG(), OPT__COLOR(), and parse_opt_color_flag_cb() to the option parsing library. The callback uses git_config_colorbool(), so color.h is now a dependency of parse-options.c. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-16grep documentation: clarify what files matchLibravatar Mark Lodato1-5/+12
Clarify that git-grep(1) searches only tracked files, and that each <pathspec> is a pathspec, as in any other ordinary git commands. Add an example to show a simple use case for searching all .c and .h files in the current directory and below. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-28grep --quiet: finishing touchesLibravatar Junio C Hamano1-1/+6
Name the option "--quiet" not "--quick", document it, and add tests. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-1/+1
The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.
2009-07-22grep: Add --max-depth option.Libravatar Michał Kiedrowicz1-0/+5
It is useful to grep directories non-recursively, e.g. when one wants to look for all files in the toplevel directory, but not in any subdirectory, or in Documentation/, but not in Documentation/technical/. This patch adds support for --max-depth <depth> option to git-grep. If it is given, git-grep descends at most <depth> levels of directories below paths specified on the command line. Note that if path specified on command line contains wildcards, this option makes no sense, e.g. $ git grep -l --max-depth 0 GNU -- 'contrib/*' (note the quotes) will search all files in contrib/, even in subdirectories, because '*' matches all files. Documentation updates, bash-completion and simple test cases are also provided. Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-01grep -p: support user defined regular expressionsLibravatar René Scharfe1-0/+3
Respect the userdiff attributes and config settings when looking for lines with function definitions in git grep -p. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-01grep: add option -p/--show-functionLibravatar René Scharfe1-0/+5
The new option -p instructs git grep to print the previous function definition as a context line, similar to diff -p. Such context lines are marked with an equal sign instead of a dash. This option complements the existing context options -A, -B, -C. Function definitions are detected using the same heuristic that diff uses. User defined regular expressions are not supported, yet. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-07grep: color patterns in outputLibravatar René Scharfe1-0/+8
Coloring matches makes them easier to spot in the output. Add two options and two parameters: color.grep (to turn coloring on or off), color.grep.match (to set the color of matches), --color and --no-color (to turn coloring on or off, respectively). The output of external greps is not changed. This patch is based on earlier ones by Nguyễn Thái Ngọc Duy and Thiago Alves. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-01git grep: Add "-z/--null" option as in GNU's grep.Libravatar Raphael Zimmerer1-0/+6
Here's a trivial patch that adds "-z" and "--null" options to "git grep". It was discussed on the mailing-list that git's "-z" convention should be used instead of GNU grep's "-Z". So things like 'git grep -l -z "$FOO" | xargs -0 sed -i "s/$FOO/$BOO/"' do work now. Signed-off-by: Raphael Zimmerer <killekulla@rdrz.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-1/+1
The names of git commands are not meant to be entered at the commandline; they are just names. So we render them in italics, as is usual for command names in manpages. Using doit () { perl -e 'for (<>) { s/\`(git-[^\`.]*)\`/'\''\1'\''/g; print }' } for i in git*.txt config.txt diff*.txt blame*.txt fetch*.txt i18n.txt \ merge*.txt pretty*.txt pull*.txt rev*.txt urls*.txt do doit <"$i" >"$i+" && mv "$i+" "$i" done git diff . Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01Documentation formatting and cleanupLibravatar Jonathan Nieder1-1/+1
Following what appears to be the predominant style, format names of commands and commandlines both as `teletype text`. While we're at it, add articles ("a" and "the") in some places, italicize the name of the command in the manual page synopsis line, and add a comma or two where it seems appropriate. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01Documentation: be consistent about "git-" versus "git "Libravatar Jonathan Nieder1-1/+1
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 <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-08Docs: Use "-l::\n--long\n" format in OPTIONS sectionsLibravatar Stephan Beyer1-10/+27
The OPTIONS section of a documentation file contains a list of the options a git command accepts. Currently there are several variants to describe the case that different options (almost) do the same in the OPTIONS section. Some are: -f, --foo:: -f|--foo:: -f | --foo:: But AsciiDoc has the special form: -f:: --foo:: This patch applies this form to the documentation of the whole git suite, and removes useless em-dash prevention, so \--foo becomes --foo. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>