summaryrefslogtreecommitdiff
path: root/Documentation/config.txt
AgeCommit message (Collapse)AuthorFilesLines
2012-11-18Documentation: move diff.wordRegex from config.txt to diff-config.txtLibravatar Ramkumar Ramachandra1-6/+0
19299a8 (Documentation: Move diff.<driver>.* from config.txt to diff-config.txt, 2011-04-07) moved the diff configuration options to diff-config.txt, but forgot about diff.wordRegex, which was left behind in config.txt. Fix this. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-04Merge branch 'pp/maint-doc-pager-config'Libravatar Jeff King1-4/+4
* pp/maint-doc-pager-config: Documentation: improve the example of overriding LESS via core.pager
2012-10-29Documentation: improve the example of overriding LESS via core.pagerLibravatar Patrick Palka1-4/+4
You can override an option set in the LESS variable by simply prefixing the command line option with `-+`. This is more robust than the previous example if the default LESS options are to ever change. Signed-off-by: Patrick Palka <patrick@parcs.ath.cx> Signed-off-by: Jeff King <peff@peff.net>
2012-09-17Merge branch 'maint'Libravatar Junio C Hamano1-2/+3
* 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-17Documentation: indent-with-non-tab uses "equivalent tabs" not 8Libravatar Wesley J. Landaker1-2/+3
Update the documentation of the core.whitespace option "indent-with-non-tab" to correctly reflect that it catches the use of spaces instead of the equivalent tabs, rather than a fixed number. Signed-off-by: Wesley J. Landaker <wjl@icecavern.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Merge branch 'js/grep-patterntype-config'Libravatar Junio C Hamano1-1/+9
"grep" learned to use a non-standard pattern type by default if a configuration variable tells it to. * js/grep-patterntype-config: grep: add a grep.patternType configuration setting
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-07-30Merge branch 'pg/maint-1.7.9-am-where-is-patch' into maintLibravatar Junio C Hamano1-0/+3
When "git am" failed, old timers knew to check .git/rebase-apply/patch to see what went wrong, but we never told the users about it. * pg/maint-1.7.9-am-where-is-patch: am: indicate where a failed patch is to be found
2012-07-22Merge branch 'pg/maint-1.7.9-am-where-is-patch'Libravatar Junio C Hamano1-0/+3
When "git am" failed, old timers knew to check .git/rebase-apply/patch to see what went wrong, but we never told the users about it. * pg/maint-1.7.9-am-where-is-patch: am: indicate where a failed patch is to be found
2012-07-13am: indicate where a failed patch is to be foundLibravatar Paul Gortmaker1-0/+3
If "git am" fails to apply something, the end user may need to know where to find the patch that failed to apply, so that the user can do other things (e.g. trying "GNU patch" on it, running "diffstat" to see what it tried to change, etc.) The input to "am" may have contained more than one patch, or the message may have been MIME encoded, and knowing what the user fed to "am" does not help very much for this purpose. Also introduce advice.amworkdir configuration to allow people who learned where to look to squelch this message. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-13Merge branch 'tb/sanitize-decomposed-utf-8-pathname'Libravatar Junio C Hamano1-0/+9
Teaches git to normalize pathnames read from readdir(3) and all arguments from the command line into precomposed UTF-8 (assuming that they come as decomposed UTF-8) to work around issues on Mac OS. I think there still are other places that need conversion (e.g. paths that are read from stdin for some commands), but this should be a good first step in the right direction. * tb/sanitize-decomposed-utf-8-pathname: git on Mac OS and precomposed unicode
2012-07-09Merge branch 'mm/config-xdg'Libravatar Junio C Hamano1-2/+6
Teach git to read various information from $XDG_CONFIG_HOME/git/ to allow the user to avoid cluttering $HOME. * mm/config-xdg: config: write to $XDG_CONFIG_HOME/git/config file when appropriate Let core.attributesfile default to $XDG_CONFIG_HOME/git/attributes Let core.excludesfile default to $XDG_CONFIG_HOME/git/ignore config: read (but not write) from $XDG_CONFIG_HOME/git/config file
2012-07-08git on Mac OS and precomposed unicodeLibravatar Torsten Bögershausen1-0/+9
Mac OS X mangles file names containing unicode on file systems HFS+, VFAT or SAMBA. When a file using unicode code points outside ASCII is created on a HFS+ drive, the file name is converted into decomposed unicode and written to disk. No conversion is done if the file name is already decomposed unicode. Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same result as open("\x41\xcc\x88",...) with a decomposed "Ä". As a consequence, readdir() returns the file names in decomposed unicode, even if the user expects precomposed unicode. Unlike on HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in precomposed unicode, but readdir() still returns file names in decomposed unicode. When a git repository is stored on a network share using SAMBA, file names are send over the wire and written to disk on the remote system in precomposed unicode, but Mac OS X readdir() returns decomposed unicode to be compatible with its behaviour on HFS+ and VFAT. The unicode decomposition causes many problems: - The names "git add" and other commands get from the end user may often be precomposed form (the decomposed form is not easily input from the keyboard), but when the commands read from the filesystem to see what it is going to update the index with already is on the filesystem, readdir() will give decomposed form, which is different. - Similarly "git log", "git mv" and all other commands that need to compare pathnames found on the command line (often but not always precomposed form; a command line input resulting from globbing may be in decomposed) with pathnames found in the tree objects (should be precomposed form to be compatible with other systems and for consistency in general). - The same for names stored in the index, which should be precomposed, that may need to be compared with the names read from readdir(). NFS mounted from Linux is fully transparent and does not suffer from the above. As Mac OS X treats precomposed and decomposed file names as equal, we can - wrap readdir() on Mac OS X to return the precomposed form, and - normalize decomposed form given from the command line also to the precomposed form, to ensure that all pathnames used in Git are always in the precomposed form. This behaviour can be requested by setting "core.precomposedunicode" configuration variable to true. The code in compat/precomposed_utf8.c implements basically 4 new functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(), precomposed_utf8_closedir() and precompose_argv(). The first three are to wrap opendir(3), readdir(3), and closedir(3) functions. The argv[] conversion allows to use the TAB filename completion done by the shell on command line. It tolerates other tools which use readdir() to feed decomposed file names into git. When creating a new git repository with "git init" or "git clone", "core.precomposedunicode" will be set "false". The user needs to activate this feature manually. She typically sets core.precomposedunicode to "true" on HFS and VFAT, or file systems mounted via SAMBA. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03Fix formatting in git-config(1)Libravatar Andreas Schwab1-7/+9
This fixes two formatting bugs in the git-config documentation: - in the column.ui entry don't indent the last paragraph so that it isn't formatted as a literal paragraph - in the push.default entry separate the last paragraph from the nested list. Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-25Let core.attributesfile default to $XDG_CONFIG_HOME/git/attributesLibravatar Huynh Khoi Nguyen Nguyen1-1/+3
This gives the default value for the core.attributesfile variable following the exact same logic of the previous change for the core.excludesfile setting. 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-25Let core.excludesfile default to $XDG_CONFIG_HOME/git/ignoreLibravatar Huynh Khoi Nguyen Nguyen1-1/+3
To use the feature of core.excludesfile, the user needs: 1. to create such a file, 2. and add configuration variable to point at it. Instead, we can make this a one-step process by choosing a default value which points to a filename in the user's $HOME, that is unlikely to already exist on the system, and only use the presence of the file as a cue that the user wants to use that feature. And we use "${XDG_CONFIG_HOME:-$HOME/.config/git}/ignore" as such a file, in the same directory as the newly added configuration file ("${XDG_CONFIG_HOME:-$HOME/.config/git}/config). The use of this directory is in line with XDG specification as a location to store such application specific files. 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-14wt-status.*: better advices for git status addedLibravatar Lucien Kong1-3/+4
This patch provides new informative help messages in the display of 'git status' (at the top) during conflicts, rebase, am, bisect or cherry-pick process. The new messages are not shown when using options such as -s or --porcelain. The messages about the current situation of the user are always displayed but the advices on what the user needs to do in order to resume a rebase/bisect/am/commit after resolving conflicts can be hidden by setting advice.statushints to 'false' in the config file. Thus, information about the updated advice.statushints key are added in Documentation/config.txt. Also, the test t7060-wt-status.sh is now working with the new help messages. Tests about suggestions of "git rm" are also added. Signed-off-by: Lucien Kong <Lucien.Kong@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: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-03Merge branch 'nd/columns'Libravatar Junio C Hamano1-0/+38
A couple of commands learn --column option to produce columnar output. By Nguyễn Thái Ngọc Duy (9) and Zbigniew Jędrzejewski-Szmek (1) * nd/columns: tag: add --column column: support piping stdout to external git-column process status: add --column branch: add --column help: reuse print_columns() for help -a column: add dense layout support t9002: work around shells that are unable to set COLUMNS to 1 column: add columnar layout Stop starting pager recursively Add column layout skeleton and git-column
2012-05-03doc/config: fix inline literalsLibravatar Jeff King1-2/+2
Since commit 6cf378f, asciidoc backticks are now inline literals; therefore quoting {tilde} inside them is wrong (this instance was missed in 6cf378f because it happened on a parallel line of development). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-02Merge branch 'jk/doc-asciidoc-inline-literal'Libravatar Junio C Hamano1-18/+18
Our documentation was written for an ancient version of AsciiDoc, making the source not very readable. By Jeff King * jk/doc-asciidoc-inline-literal: docs: stop using asciidoc no-inline-literal
2012-05-02Merge branch 'mm/simple-push'Libravatar Junio C Hamano1-4/+22
New users tend to work on one branch at a time and push the result out. The current and upstream modes of push is a more suitable default mode than matching mode for these people, but neither is surprise-free depending on how the project is set up. Introduce a "simple" mode that is a subset of "upstream" but only works when the branch is named the same between the remote and local repositories. The plan is to make it the new default when push.default is not configured. By Matthieu Moy (5) and others * mm/simple-push: push.default doc: explain simple after upstream push: document the future default change for push.default (matching -> simple) t5570: use explicit push refspec push: introduce new push.default mode "simple" t5528-push-default.sh: add helper functions Undocument deprecated alias 'push.default=tracking' Documentation: explain push.default option a bit more
2012-04-29Merge branch 'mm/include-userpath'Libravatar Junio C Hamano1-1/+4
The new "include.path" directive in the configuration files learned to understand "~/path" and "~user/path". By Jeff King * mm/include-userpath: config: expand tildes in include.path variable
2012-04-29config: expand tildes in include.path variableLibravatar Jeff King1-1/+4
You can already use relative paths in include.path, which means that including "foo" from your global "~/.gitconfig" will look in your home directory. However, you might want to do something clever like putting "~/.gitconfig-foo" in a specific repository's config file. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27tag: add --columnLibravatar Nguyễn Thái Ngọc Duy1-0/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27status: add --columnLibravatar Nguyễn Thái Ngọc Duy1-0/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27branch: add --columnLibravatar Nguyễn Thái Ngọc Duy1-0/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27column: add dense layout supportLibravatar Nguyễn Thái Ngọc Duy1-0/+4
Normally all cells (and in turn columns) share the same width. This layout mode can waste space because one long item can stretch our all columns. With COL_DENSE enabled, column width is calculated indepdendently. All columns are shrunk to minimum, then it attempts to push cells of the last row over to the next column with hope that everything still fits even there's one row less. The process is repeated until the new layout cannot fit in given width any more, or there's only one row left (perfect!). Apparently, this mode consumes more cpu than the old one, but it makes better use of terminal space. For layouting one or two screens, cpu usage should not be detectable. This patch introduces option handling code besides layout modes and enable/disable to expose this feature as "dense". The feature can be turned off by specifying "nodense". Thanks-to: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27column: add columnar layoutLibravatar Nguyễn Thái Ngọc Duy1-0/+4
COL_COLUMN and COL_ROW fill column by column (or row by row respectively), given the terminal width and how many space between columns. All cells have equal width. Strings are supposed to be in UTF-8. Valid ANSI escape strings are OK. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27Add column layout skeleton and git-columnLibravatar Nguyễn Thái Ngọc Duy1-0/+18
A column option string consists of many token separated by either a space or a comma. A token belongs to one of three groups: - enabling: always, never and auto - layout mode: currently plain (which does not layout at all) - other future tuning flags git-column can be used to pipe output to from a command that wants column layout, but not to mess with its own output code. Simpler output code can be changed to use column layout code directly. Thanks-to: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-18/+18
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-04-24push.default doc: explain simple after upstreamLibravatar Junio C Hamano1-4/+4
As the "simple" mode is described in terms of what "upstream" does, swap the order of these two entries so that the reader sees "upstream" first and then reads "simple" with the knowledge of what "upstream" does. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24push: document the future default change for push.default (matching -> simple)Libravatar Matthieu Moy1-2/+6
It is too early to start warning loudly about the future default change in favor of 'simple', since many users use different versions of Git, and would be harmed if we advised them to explicitely set 'push.default=simple' when using old versions of Git. Still, we want to document the upcomming change so that: * Users who may be affected by the change get one more chance to know it in advance. * We actually commit to changing the default, and avoid repeating past errors. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24push: introduce new push.default mode "simple"Libravatar Matthieu Moy1-1/+4
When calling "git push" without argument, we want to allow Git to do something simple to explain and safe. push.default=matching is unsafe when used to push to shared repositories, and hard to explain to beginners in some contexts. It is debatable whether 'upstream' or 'current' is the safest or the easiest to explain, so introduce a new mode called 'simple' that is the intersection of them: push to the upstream branch, but only if it has the same name remotely. If not, give an error that suggests the right command to push explicitely to 'upstream' or 'current'. A question is whether to allow pushing when no upstream is configured. An argument in favor of allowing the push is that it makes the new mode work in more cases. On the other hand, refusing to push when no upstream is configured encourages the user to set the upstream, which will be beneficial on the next pull. Lacking better argument, we chose to deny the push, because it will be easier to change in the future if someone shows us wrong. Original-patch-by: Jeff King <peff@peff.net> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24Undocument deprecated alias 'push.default=tracking'Libravatar Matthieu Moy1-1/+0
It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011, push.default: Rename 'tracking' to 'upstream'), so it's OK to remove it from documentation (even though it's still supported) to make the explanations more readable. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24Documentation: explain push.default option a bit moreLibravatar Matthieu Moy1-3/+15
The previous documentation was explaining _what_ the options were doing, but were of little help explaining _why_ a user should set his default to either of the options. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-19push: Provide situational hints for non-fast-forward errorsLibravatar Christopher Tiwald1-2/+17
Pushing a non-fast-forward update to a remote repository will result in an error, but the hint text doesn't provide the correct resolution in every case. Give better resolution advice in three push scenarios: 1) If you push your current branch and it triggers a non-fast-forward error, you should merge remote changes with 'git pull' before pushing again. 2) If you push to a shared repository others push to, and your local tracking branches are not kept up to date, the 'matching refs' default will generate non-fast-forward errors on outdated branches. If this is your workflow, the 'matching refs' default is not for you. Consider setting the 'push.default' configuration variable to 'current' or 'upstream' to ensure only your current branch is pushed. 3) If you explicitly specify a ref that is not your current branch or push matching branches with ':', you will generate a non-fast-forward error if any pushed branch tip is out of date. You should checkout the offending branch and merge remote changes before pushing again. Teach transport.c to recognize these scenarios and configure push.c to hint for them. If 'git push's default behavior changes or we discover more scenarios, extension is easy. Standardize on the advice API and add three new advice variables, 'pushNonFFCurrent', 'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these to 'false' will disable their affiliated advice. Setting 'pushNonFastForward' to false will disable all three, thus preserving the config option for users who already set it, but guaranteeing new users won't disable push advice accidentally. Based-on-patch-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Christopher Tiwald <christiwald@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-04Merge branch 'maint'Libravatar Junio C Hamano1-3/+4
* maint: Update draft release notes to 1.7.9.3 for the last time http.proxy: also mention https_proxy and all_proxy t0300: work around bug in dash 0.5.6 t5512 (ls-remote): modernize style tests: fix spurious error when run directly with Solaris /usr/xpg4/bin/sh
2012-03-04http.proxy: also mention https_proxy and all_proxyLibravatar Clemens Buchacher1-3/+4
The current wording of the http.proxy documentation suggests that http_proxy is somehow equivalent to http.proxy. However, while http.proxy (by the means of curl's CURLOPT_PROXY option) overrides the proxy for both HTTP and HTTPS protocols, the http_proxy environment variable is used only for HTTP. But since the docs mention only http_proxy, a user might expect it to apply to all HTTP-like protocols. Avoid any such misunderstanding by explicitly mentioning https_proxy and all_proxy as well. Also replace linkgit:curl[1] with a literal 'curl(1)', because the former gets translated to a dead link in the HTML pages. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-01Merge branch 'maint'Libravatar Junio C Hamano1-5/+7
* maint: Documentation fixes in git-config
2012-03-01Documentation fixes in git-configLibravatar Libor Pechacek1-5/+7
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/+15
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>
2012-01-10Sync with maintLibravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10Merge the attributes fix in from maint-1.6.7 branchLibravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10Merge the attributes fix in from maint-1.6.6 branchLibravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10Documentation: rerere's rr-cache auto-creation and rerere.enabledLibravatar Junio C Hamano1-1/+2
The description of rerere.enabled left the user in the dark as to who might create an rr-cache directory. Add a note that simply invoking rerere does this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-06Merge branch 'jc/show-sig'Libravatar Junio C Hamano1-0/+11
* jc/show-sig: log --show-signature: reword the common two-head merge case log-tree: show mergetag in log --show-signature output log-tree.c: small refactor in show_signature() commit --amend -S: strip existing gpgsig headers verify_signed_buffer: fix stale comment gpg-interface: allow use of a custom GPG binary pretty: %G[?GS] placeholders test "commit -S" and "log --show-signature" log: --show-signature commit: teach --gpg-sign option Conflicts: builtin/commit-tree.c builtin/commit.c builtin/merge.c notes-cache.c pretty.c
2012-01-06Sync with 1.7.8.3Libravatar Junio C Hamano1-4/+4
2012-01-06Merge branch 'maint-1.7.7' into maintLibravatar Junio C Hamano1-4/+4
* maint-1.7.7: Documentation: rerere.enabled is the primary way to configure rerere
2012-01-06Merge branch 'maint-1.7.6' into maint-1.7.7Libravatar Junio C Hamano1-4/+4
* maint-1.7.6: Documentation: rerere.enabled is the primary way to configure rerere
2012-01-06Documentation: rerere.enabled is the primary way to configure rerereLibravatar Thomas Rast1-4/+4
The wording seems to suggest that creating the directory is needed and the setting of rerere.enabled is only for disabling the feature by setting it to 'false'. But the configuration is meant to be the primary control and setting it to 'true' will enable it; the rr-cache directory will be created as necessary and the user does not have to create it. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>