summaryrefslogtreecommitdiff
path: root/Documentation/git-config.txt
AgeCommit message (Collapse)AuthorFilesLines
2013-07-12Merge branch 'jk/maint-config-multi-order'Libravatar Junio C Hamano1-8/+12
* jk/maint-config-multi-order: git-config(1): clarify precedence of multiple values
2013-07-07git-config(1): clarify precedence of multiple valuesLibravatar John Keeping1-8/+12
In order to clarify which value is used when there are multiple values defined for a key, re-order the list of file locations so that it runs from least specific to most specific. Then add a paragraph which simply says that the last value will be used. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-03Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Update draft release notes to 1.8.3.3 git-config: update doc for --get with multiple values
2013-07-03Merge branch 'maint-1.8.2' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.8.2: git-config: update doc for --get with multiple values
2013-07-03git-config: update doc for --get with multiple valuesLibravatar John Keeping1-1/+1
Since commit 00b347d (git-config: do not complain about duplicate entries, 2012-10-23), "git config --get" does not exit with an error if there are multiple values for the specified key but instead returns the last value. Update the documentation to reflect this. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-24Merge branch 'nk/config-local-doc'Libravatar Junio C Hamano1-0/+9
* nk/config-local-doc: config: Add description of --local option
2013-06-17config: Add description of --local optionLibravatar Namhyung Kim1-0/+9
It was missed in the option list while mentioned from the general description. Add it for completeness. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-17documentation: trivial style cleanupsLibravatar Felipe Contreras1-2/+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-01-11Merge branch 'jn/warn-on-inaccessible-loosen' into maintLibravatar Junio C Hamano1-0/+4
When attempting to read the XDG-style $HOME/.config/git/config and finding that $HOME/.config/git is a file, we gave a wrong error message, instead of treating the case as "a custom config file does not exist there" and moving on. * jn/warn-on-inaccessible-loosen: config: exit on error accessing any config file doc: advertise GIT_CONFIG_NOSYSTEM config: treat user and xdg config permission problems as errors config, gitignore: failure to access with ENOTDIR is ok
2013-01-06Merge branch 'jn/warn-on-inaccessible-loosen'Libravatar Junio C Hamano1-0/+4
Deal with a situation where .config/git is a file and we notice .config/git/config is not readable due to ENOTDIR, not ENOENT. * jn/warn-on-inaccessible-loosen: config: exit on error accessing any config file doc: advertise GIT_CONFIG_NOSYSTEM config: treat user and xdg config permission problems as errors config, gitignore: failure to access with ENOTDIR is ok
2012-10-14doc: advertise GIT_CONFIG_NOSYSTEMLibravatar Jonathan Nieder1-0/+4
On a multiuser system where mortals do not have write access to /etc, the GIT_CONFIG_NOSYSTEM variable is the best tool we have to keep getting work done when a syntax error or other problem renders /etc/gitconfig buggy, until the sysadmin sorts the problem out. Noticed while experimenting with teaching git to error out when /etc/gitconfig is unreadable. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-03Merge branch 'jc/maint-config-exit-status'Libravatar Junio C Hamano1-4/+4
The exit status code from "git config" was way overspecified while being incorrect. Update the implementation to give the documented status for a case that was documented, and introduce a new code for "all other errors". * jc/maint-config-exit-status: config: "git config baa" should exit with status 1
2012-08-29Merge branch 'mh/maint-config-doc-proxy-command'Libravatar Junio C Hamano1-2/+2
* mh/maint-config-doc-proxy-command: git-config doc: unconfuse an example git-config.txt: fix example
2012-08-18git-config doc: unconfuse an exampleLibravatar Junio C Hamano1-1/+1
One fictitious command "proxy-command" is enclosed inside a double quote pair, while another fictitious command "default-proxy" is not in the example, but the quoting does not change anything in the pair of examples. Remove the quotes to avoid unnecessary confusion. Noticed by Michael Haggerty. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-18git-config.txt: fix exampleLibravatar Michael Haggerty1-1/+1
The "--add" option is required to add a new value to a multivalued configuration entry. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-30config: "git config baa" should exit with status 1Libravatar Junio C Hamano1-4/+4
We instead failed with an undocumented exit status 255. Also define a "catch-all" status and document it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-25config: write to $XDG_CONFIG_HOME/git/config file when appropriateLibravatar Huynh Khoi Nguyen Nguyen1-1/+2
Teach git to write to $XDG_CONFIG_HOME/git/config if - it already exists, - $HOME/.gitconfig file doesn't, and - The --global option is used. Otherwise, write to $HOME/.gitconfig when the --global option is given, as before. If the user doesn't create $XDG_CONFIG_HOME/git/config, there is absolutely no change. Users can use this new file only if they want. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/config will be used. Advice for users who often come back to an old version of Git: you shouldn't create this file. Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-25config: read (but not write) from $XDG_CONFIG_HOME/git/config fileLibravatar Huynh Khoi Nguyen Nguyen1-3/+11
Teach git to read the "gitconfig" information from a new location, $XDG_CONFIG_HOME/git/config; this allows the user to avoid cluttering $HOME with many per-application configuration files. In the order of reading, this file comes between the global configuration file (typically $HOME/.gitconfig) and the system wide configuration file (typically /etc/gitconfig). We do not write to this new location (yet). If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/config will be used. This is in line with XDG specification. If the new file does not exist, the behavior is unchanged. Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-25config doc: remove confusion about relative GIT_DIR from FILES sectionLibravatar Jonathan Nieder1-3/+1
From the FILES section of the git-config(1) manual: $GIT_DIR/config:: Repository specific configuration file. (The filename is of course relative to the repository root, not the working directory.) That's confusing because $GIT_DIR really is relative to the working directory. $ GIT_DIR=.git GIT_EDITOR='pwd; echo editing' $ export GIT_DIR GIT_EDITOR $ git config --edit --local /home/jrn/src/git/Documentation editing .git/config It turns out that the comment is a remnant from older days when the heading said ".git/config" (which is indeed relative to the top of the worktree). It was only when the heading was changed to refer more precisely to <git dir>/config (see v1.5.3.2~18, AsciiDoc tweak to avoid leading dot, 2007-09-14) that the parenthesis stopped making sense. Remove it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-11Merge branch 'fa/maint-config-doc' into maintLibravatar Junio C Hamano1-5/+9
By Florian Achleitner * fa/maint-config-doc: Documentation/git-config: describe and clarify "--local <file>" option
2012-05-07Documentation/git-config: describe and clarify "--local <file>" optionLibravatar Florian Achleitner1-5/+9
Describe config file selection in git-config. While the usage message of git-config shows --local, the documentation page did not contain anything about that. Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-01Merge branch 'maint'Libravatar Junio C Hamano1-2/+5
* maint: Documentation fixes in git-config
2012-03-01Documentation fixes in git-configLibravatar Libor Pechacek1-2/+5
Variable names must start with an alphabetic character, regexp config key matching has its limits, sentence grammar. Signed-off-by: Libor Pechacek <lpechacek@suse.cz> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-17config: add include directiveLibravatar Jeff King1-0/+5
It can be useful to split your ~/.gitconfig across multiple files. For example, you might have a "main" file which is used on many machines, but a small set of per-machine tweaks. Or you may want to make some of your config public (e.g., clever aliases) while keeping other data back (e.g., your name or other identifying information). Or you may want to include a number of config options in some subset of your repos without copying and pasting (e.g., you want to reference them from the .git/config of participating repos). This patch introduces an include directive for config files. It looks like: [include] path = /path/to/file This is syntactically backwards-compatible with existing git config parsers (i.e., they will see it as another config entry and ignore it unless you are looking up include.path). The implementation provides a "git_config_include" callback which wraps regular config callbacks. Callers can pass it to git_config_from_file, and it will transparently follow any include directives, passing all of the discovered options to the real callback. Include directives are turned on automatically for "regular" git config parsing. This includes calls to git_config, as well as calls to the "git config" program that do not specify a single file (e.g., using "-f", "--global", etc). They are not turned on in other cases, including: 1. Parsing of other config-like files, like .gitmodules. There isn't a real need, and I'd rather be conservative and avoid unnecessary incompatibility or confusion. 2. Reading single files via "git config". This is for two reasons: a. backwards compatibility with scripts looking at config-like files. b. inspection of a specific file probably means you care about just what's in that file, not a general lookup for "do we have this value anywhere at all". If that is not the case, the caller can always specify "--includes". 3. Writing files via "git config"; we want to treat include.* variables as literal items to be copied (or modified), and not expand them. So "git config --unset-all foo.bar" would operate _only_ on .git/config, not any of its included files (just as it also does not operate on ~/.gitconfig). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-17config: define and document exit codesLibravatar Michael J Gruber1-10/+12
The return codes of git_config_set() and friends are magic numbers right in the source. #define them in cache.h where the functions are declared, and use the constants in the source. Also, mention the resulting exit codes of "git config" in its man page (and complete the list). Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-9/+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-01-20Merge remote branch 'remotes/trast-doc/for-next'Libravatar Junio C Hamano1-7/+7
* remotes/trast-doc/for-next: Documentation: spell 'git cmd' without dash throughout Documentation: format full commands in typewriter font Documentation: warn prominently against merging with dirty trees Documentation/git-merge: reword references to "remote" and "pull" Conflicts: Documentation/config.txt Documentation/git-config.txt Documentation/git-merge.txt
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-7/+7
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-12-31builtin-config: add --path option doing ~ and ~user expansion.Libravatar Matthieu Moy1-3/+11
395de250 (Expand ~ and ~user in core.excludesfile, commit.template) introduced a C function git_config_pathname, doing ~/ and ~user/ expansion. This patch makes the feature available to scripts with 'git config --get --path'. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-09git config: clarify --add and --get-colorLibravatar Felipe Contreras1-2/+3
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-20Merge branch 'fc/parseopt-config'Libravatar Junio C Hamano1-1/+1
* fc/parseopt-config: config: test for --replace-all with one argument and fix documentation. config: set help text for --bool-or-int git config: don't allow --get-color* and variable type git config: don't allow extra arguments for -e or -l. git config: don't allow multiple variable types git config: don't allow multiple config file locations git config: reorganize to use parseopt git config: reorganize get_color* git config: trivial rename in preparation for parseopt git_config(): not having a per-repo config file is not an error
2009-03-17config: test for --replace-all with one argument and fix documentation.Libravatar Carlos Rica1-1/+1
Option --replace-all only allows at least two arguments, so documentation was needing to be updated accordingly. A test showing that the command fails with only one parameter is also provided. Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-07Merge branch 'maint'Libravatar Junio C Hamano1-0/+4
* maint: builtin-revert.c: release index lock when cherry-picking an empty commit document config --bool-or-int t1300: use test_must_fail as appropriate cleanup: add isascii() Documentation: fix badly indented paragraphs in "--bisect-all" description
2009-03-07document config --bool-or-intLibravatar Jeff King1-0/+4
The documentation is just a pointer to the --bool and --int options, but it makes sense to at least mention that it exists. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-08config: Add new option to open an editor.Libravatar Felipe Contreras1-0/+6
The idea was originated by discussion about usability of manually editing the config file in 'special needs' systems such as Windows. Now the user can forget a bit about where the config files actually are. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-12git-config.txt: fix a typoLibravatar Jim Meyering1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-27Documentation: fix diff.external exampleLibravatar Anders Melchiorsen1-1/+1
The diff.external examples pass a flag to gnu-diff, but GNU diff does not follow the GIT_EXTERNAL_DIFF interface. Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-07Merge branch 'db/no-git-config'Libravatar Junio C Hamano1-9/+0
* db/no-git-config: Only use GIT_CONFIG in "git config", not other programs Conflicts: Documentation/RelNotes-1.6.0.txt
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-6/+6
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-6/+6
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-13/+13
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-07-01Only use GIT_CONFIG in "git config", not other programsLibravatar Daniel Barkalow1-9/+0
For everything other than using "git config" to read or write a git-style config file that isn't the current repo's config file, GIT_CONFIG was actively detrimental. Rather than argue over which programs are important enough to have work anyway, just fix all of them at the root. Also removes GIT_LOCAL_CONFIG, which would only be useful for programs that do want to use global git-specific config, but not the repo's own git-specific config, and want to use some other, presumably git-specific config. Despite being documented, I can't find any sign that it was ever used. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-08Docs: Use "-l::\n--long\n" format in OPTIONS sectionsLibravatar Stephan Beyer1-3/+6
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>
2008-06-06documentation: move git(7) to git(1)Libravatar Christian Couder1-1/+1
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 <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-10Use color.ui variable in scripts tooLibravatar Matthias Kestenholz1-0/+2
Signed-off-by: Matthias Kestenholz <mk@spinlock.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-29fix doc typosLibravatar Jim Meyering1-1/+1
Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-06Documentation: rename gitlink macro to linkgitLibravatar Dan McGee1-1/+1
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 <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-05git config --get-colorboolLibravatar Junio C Hamano1-0/+10
This adds an option to help scripts find out color settings from the configuration file. git config --get-colorbool color.diff inspects color.diff variable, and exits with status 0 (i.e. success) if color is to be used. It exits with status 1 otherwise. If a script wants "true"/"false" answer to the standard output of the command, it can pass an additional boolean parameter to its command line, telling if its standard output is a terminal, like this: git config --get-colorbool color.diff true When called like this, the command outputs "true" to its standard output if color is to be used (i.e. "color.diff" says "always", "auto", or "true"), and "false" otherwise. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-28git-config --get-color: get configured colorLibravatar Junio C Hamano1-0/+16
This new option allows scripts to grab color setting from the user configuration, translated to ANSI color escape sequence. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14Documentation/git-config.txt: AsciiDoc tweak to avoid leading dotLibravatar Junio C Hamano1-1/+1
Bram Schoenmakers noticed that git-config document was formatted incorrectly. Depending on the version of AsciiDoc and docbook toolchain, it is sometimes taken as a numbered example by AsciiDoc, some other times passed intact to roff format to confuse "man". Since we refer to the repository metadata directory as $GIT_DIR elsewhere, work it around by using that symbolic name. Signed-off-by: Junio C Hamano <gitster@pobox.com>