summaryrefslogtreecommitdiff
path: root/Documentation/git-config.txt
AgeCommit message (Collapse)AuthorFilesLines
2018-04-23builtin/config: introduce `color` type specifierLibravatar Taylor Blau1-0/+6
As of this commit, the canonical way to retreive an ANSI-compatible color escape sequence from a configuration file is with the `--get-color` action. This is to allow Git to "fall back" on a default value for the color should the given section not exist in the specified configuration(s). With the addition of `--default`, this is no longer needed since: $ git config --default red --type=color core.section will be have exactly as: $ git config --get-color core.section red For consistency, let's introduce `--type=color` and encourage its use with `--default` together over `--get-color` alone. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-23builtin/config: introduce `--default`Libravatar Taylor Blau1-0/+4
For some use cases, callers of the `git-config(1)` builtin would like to fallback to default values when the variable asked for does not exist. In addition, users would like to use existing type specifiers to ensure that values are parsed correctly when they do exist in the configuration. For example, to fetch a value without a type specifier and fallback to `$fallback`, the following is required: $ git config core.foo || echo "$fallback" This is fine for most values, but can be tricky for difficult-to-express `$fallback`'s, like ANSI color codes. This motivates `--get-color`, which is a one-off exception to the normal type specifier rules wherein a user specifies both the configuration variable and an optional fallback. Both are formatted according to their type specifier, which eases the burden on the user to ensure that values are correctly formatted. This commit (and those following it in this series) aim to eventually replace `--get-color` with a consistent alternative. By introducing `--default`, we allow the `--get-color` action to be promoted to a `--type=color` type specifier, retaining the "fallback" behavior via the `--default` flag introduced in this commit. For example, we aim to replace: $ git config --get-color variable [default] [...] with: $ git config --default default --type=color variable [...] Values filled by `--default` behave exactly as if they were present in the affected configuration file; they will be parsed by type specifiers without the knowledge that they are not themselves present in the configuration. Specifically, this means that the following will work: $ git config --int --default 1M does.not.exist 1048576 In subsequent commits, we will offer `--type=color`, which (in conjunction with `--default`) will be sufficient to replace `--get-color`. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-19builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`Libravatar Taylor Blau1-32/+39
`git config` has long allowed the ability for callers to provide a 'type specifier', which instructs `git config` to (1) ensure that incoming values can be interpreted as that type, and (2) that outgoing values are canonicalized under that type. In another series, we propose to extend this functionality with `--type=color` and `--default` to replace `--get-color`. However, we traditionally use `--color` to mean "colorize this output", instead of "this value should be treated as a color". Currently, `git config` does not support this kind of colorization, but we should be careful to avoid squatting on this option too soon, so that `git config` can support `--color` (in the traditional sense) in the future, if that is desired. In this patch, we support `--type=<int|bool|bool-or-int|...>` in addition to `--int`, `--bool`, and etc. This allows the aforementioned upcoming patch to support querying a color value with a default via `--type=color --default=...`, without squandering `--color`. We retain the historic behavior of complaining when multiple, legacy-style `--<type>` flags are given, as well as extend this to conflicting new-style `--type=<type>` flags. `--int --type=int` (and its commutative pair) does not complain, but `--bool --type=int` (and its commutative pair) does. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-21config: change default of `pager.config` to "on"Libravatar Martin Ågren1-0/+1
This is similar to ff1e72483 (tag: change default of `pager.tag` to "on", 2017-08-02) and is safe now that we do not consider `pager.config` at all when we are not listing or getting configuration. This change will help with listing large configurations, but will not hurt users of `git config --edit` as it would have before the previous commit. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-21config: respect `pager.config` in list/get-mode onlyLibravatar Martin Ågren1-0/+5
Similar to de121ffe5 (tag: respect `pager.tag` in list-mode only, 2017-08-02), use the DELAY_PAGER_CONFIG-mechanism to only respect `pager.config` when we are listing or "get"ing config. We have several getters and some are guaranteed to give at most one line of output. Paging all getters including those could be convenient from a documentation point-of-view. The downside would be that a misconfigured or not so modern pager might wait for user interaction before terminating. Let's instead respect the config for precisely those getters which may produce more than one line of output. `--get-urlmatch` may or may not produce multiple lines of output, depending on the exact usage. Let's not try to recognize the two modes, but instead make `--get-urlmatch` always respect the config. Analyzing the detailed usage might be trivial enough here, but could establish a precedent that we will never be able to enforce throughout the codebase and that will just open a can of worms. This fixes the failing test added in the previous commit. Also adapt the test for whether `git config foo.bar bar` and `git config --get foo.bar` respects `pager.config`. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-18config: add --expiry-dateLibravatar Haaris Mehmood1-0/+5
Add --expiry-date as a data-type for config files when 'git config --get' is used. This will return any relative or fixed dates from config files as timestamps. This is useful for scripts (e.g. gc.reflogexpire) that work with timestamps so that '2.weeks' can be converted to a format acceptable by those scripts/functions. Following the convention of git_config_pathname(), move the helper function required for this feature from builtin/reflog.c to builtin/config.c where other similar functions exist (e.g. for --bool or --path), and match the order of parameters with other functions (i.e. output pointer as first parameter). Signed-off-by: Haaris Mehmood <hsed@unimetic.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-19config doc: clarify "git config --path" exampleLibravatar Nathan Payre1-4/+4
Change the word "bla" to "section.variable"; "bla" is a placeholder for a variable name but it wasn't clear for everyone. While we're here, also reformat this sample command line to use monospace instead of italics, to better match the rest of the file. Use a space instead of a dash in "git config", as is common in the rest of Git's documentation. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: MOY Matthieu <matthieu.moy@univ-lyon1.fr> Signed-off-by: Daniel Bensoussan <daniel.bensoussan--bohm@etu.univ-lyon1.fr> Signed-off-by: Timothee Albertin <timothee.albertin@etu.univ-lyon1.fr> Signed-off-by: Nathan Payre <nathan.payre@etu.univ-lyon1.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-25Merge branch 'dg/document-git-c-in-git-config-doc'Libravatar Junio C Hamano1-0/+3
The "git -c var[=val] cmd" facility to append a configuration variable definition at the end of the search order was described in git(1) manual page, but not in git-config(1), which was more likely place for people to look for when they ask "can I make a one-shot override, and if so how?" * dg/document-git-c-in-git-config-doc: doc: mention `git -c` in git-config(1)
2016-08-23doc: mention `git -c` in git-config(1)Libravatar David Glasser1-0/+3
Signed-off-by: David Glasser <glasser@davidglasser.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28doc: typeset long options with argument as literalLibravatar Matthieu Moy1-2/+2
We previously reformatted '--option' to `--option`. This patch reformats '--option <arg>' to `--option <arg>`. Obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]* <[^>]*>)'/\`\$1\`/g" *.txt Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28doc: typeset long command-line options as literalLibravatar Matthieu Moy1-13/+13
Similarly to the previous commit, use backquotes instead of forward-quotes, for long options. This was obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt and manual tweak to remove false positive in ascii-art (o'--o'--o' to describe rewritten history). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-08doc: more consistency in environment variables formatLibravatar Tom Russello1-1/+1
Wrap with backticks (monospaced font) unwrapped or single-quotes wrapped (italic type) environment variables which are followed by the word "environment". It was obtained with: perl -pi -e "s/\'?(\\\$?[0-9A-Z\_]+)\'?(?= environment ?)/\`\1\`/g" *.txt One of the main purposes is to stick to the CodingGuidelines as possible so that people writting new documentation by mimicking the existing are more likely to have it right (even if they didn't read the CodingGuidelines). Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org> Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org> Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-26config doc: improve exit code listingLibravatar Stefan Beller1-3/+3
The possible reasons for exiting are now ordered by the exit code value. While at it, rewrite the `can not write to the config file` to `the config file cannot be written` to be grammatically correct and a proper sentence. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-14Merge branch 'jk/config-get-urlmatch' into maintLibravatar Junio C Hamano1-10/+9
"git config --get-urlmatch", unlike other variants of the "git config --get" family, did not signal error with its exit status when there was no matching configuration. * jk/config-get-urlmatch: Documentation/git-config: fix --get-all description Documentation/git-config: use bulleted list for exit codes config: fail if --get-urlmatch finds no value
2016-02-28Documentation/git-config: fix --get-all descriptionLibravatar John Keeping1-2/+1
--get does not fail if a key is multi-valued, it returns the last value as described in its documentation. Clarify the description of --get-all to avoid implying that --get does fail in this case. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-28Documentation/git-config: use bulleted list for exit codesLibravatar John Keeping1-7/+7
Using a numbered list is confusing because the exit codes are not listed in order so the numbers at the start of each line do not match the exit codes described by the following text. Switch to a bulleted list so that the only number appearing on each line is the exit code described. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-28config: fail if --get-urlmatch finds no valueLibravatar John Keeping1-1/+1
The --get, --get-all and --get-regexp options to git-config exit with status 1 if the key is not found but --get-urlmatch succeeds in this case. Change --get-urlmatch to behave in the same way as the other --get* options so that all four are consistent. --get-color is a special case because it accepts a default value to return and so should not return an error if the key is not found. Also clarify this behaviour in the documentation. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-26Merge branch 'ls/config-origin'Libravatar Junio C Hamano1-5/+11
The configuration system has been taught to phrase where it found a bad configuration variable in a better way in its error messages. "git config" learnt a new "--show-origin" option to indicate where the values come from. * ls/config-origin: config: add '--show-origin' option to print the origin of a config value config: add 'origin_type' to config_source struct rename git_config_from_buf to git_config_from_mem t: do not hide Git's exit code in tests using 'nul_to_q'
2016-02-22Merge branch 'jk/config-include'Libravatar Junio C Hamano1-1/+3
* jk/config-include: git-config: better document default behavior for `--include`
2016-02-22config: add '--show-origin' option to print the origin of a config valueLibravatar Lars Schneider1-5/+11
If config values are queried using 'git config' (e.g. via --get, --get-all, --get-regexp, or --list flag) then it is sometimes hard to find the configuration file where the values were defined. Teach 'git config' the '--show-origin' option to print the source configuration file for every printed value. Based-on-patch-by: Jeff King <peff@peff.net> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-13git-config: better document default behavior for `--include`Libravatar Jeff King1-1/+3
As described in the commit message of 9b25a0b (config: add include directive, 2012-02-06), the `--include` option is only on by default in some cases. But our documentation described it as just "defaults to on", which doesn't tell the whole story. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10config: add '--name-only' option to list only variable namesLibravatar SZEDER Gábor1-3/+7
'git config' can only show values or name-value pairs, so if a shell script needs the names of set config variables it has to run 'git config --list' or '--get-regexp' and parse the output to separate config variable names from their values. However, such a parsing can't cope with multi-line values. Though 'git config' can produce null-terminated output for newline-safe parsing, that's of no use in such a case, becase shells can't cope with null characters. Even our own bash completion script suffers from these issues. Help the completion script, and shell scripts in general, by introducing the '--name-only' option to modify the output of '--list' and '--get-regexp' to list only the names of config variables, so they don't have to perform error-prone post processing to separate variable names from their values anymore. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-13*config.txt: stick to camelCase naming conventionLibravatar Nguyễn Thái Ngọc Duy1-1/+1
This should improve readability. Compare "thislongname" and "thisLongName". The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21Documentation: use "command-line" when used as a compound adjective, and fix ↵Libravatar Jason St. John1-1/+1
other minor grammatical issues Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09Merge branch 'jc/url-match'Libravatar Junio C Hamano1-0/+29
Allow section.<urlpattern>.var configuration variables to be treated as a "virtual" section.var given a URL, and use the mechanism to enhance http.* configuration variables. This is a reroll of Kyle J. McKay's work. * jc/url-match: builtin/config.c: compilation fix config: "git config --get-urlmatch" parses section.<url>.key builtin/config: refactor collect_config() config: parse http.<url>.<variable> using urlmatch config: add generic callback wrapper to parse section.<url>.key config: add helper to normalize and match URLs http.c: fix parsing of http.sslCertPasswordProtected variable
2013-08-05config: "git config --get-urlmatch" parses section.<url>.keyLibravatar Junio C Hamano1-0/+29
Using the same urlmatch_config_entry() infrastructure, add a new mode "--get-urlmatch" to the "git config" command, to learn values for the "virtual" two-level variables customized for the specific URL. git config [--<type>] --get-urlmatch <section>[.<key>] <url> With <section>.<key> fully specified, the configuration data for <section>.<urlpattern>.<key> for <urlpattern> that best matches the given <url> is sought (and if not found, <section>.<key> is used) and reported. For example, with this configuration: [http] sslVerify [http "https://weak.example.com"] cookieFile = /tmp/cookie.txt sslVerify = false You would get $ git config --bool --get-urlmatch http.sslVerify https://good.example.com true $ git config --bool --get-urlmatch http.sslVerify https://weak.example.com false With only <section> specified, you can get a list of all variables in the section with their values that apply to the given URL. E.g $ git config --get-urlmatch http https://weak.example.com http.cookiefile /tmp/cookie.txt http.sslverify false Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-31Merge branch 'rr/maint-tilde-markup-in-doc'Libravatar Junio C Hamano1-12/+14
* rr/maint-tilde-markup-in-doc: config doc: quote paths, fixing tilde-interpretation
2013-07-26config doc: quote paths, fixing tilde-interpretationLibravatar Ramkumar Ramachandra1-12/+14
The --global section of git-config(1) currently reads like: For writing options: write to global /.gitconfig file rather than the ^ start tilde repository .git/config, write to $XDG_CONFIG_HOME/git/config file if this file exists and the/.gitconfig file doesn’t. ^ end tilde Instead of tilde (~) being interpreted literally, asciidoc subscripts the text between the two tildes. To fix this problem, use backticks (`) to quote all the paths in the file uniformly, just like config.txt does. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22Merge branch 'hv/config-from-blob'Libravatar Junio C Hamano1-0/+7
Allow configuration data to be read from in-tree blob objects, which would help working in a bare repository and submodule updates. * hv/config-from-blob: do not die when error in config parsing of buf occurs teach config --blob option to parse config from database config: make parsing stack struct independent from actual data source config: drop cf validity check in get_next_char() config: factor out config file stack management
2013-07-21Merge branch 'nk/config-local-doc' into maintLibravatar Junio C Hamano1-0/+9
* nk/config-local-doc: config: Add description of --local option
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-12teach config --blob option to parse config from databaseLibravatar Heiko Voigt1-0/+7
This can be used to read configuration values directly from git's database. For example it is useful for reading to be checked out .gitmodules files directly from the database. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>