summaryrefslogtreecommitdiff
path: root/Documentation/config.txt
AgeCommit message (Collapse)AuthorFilesLines
2015-06-11Merge branch 'jk/color-diff-plain-is-context'Libravatar Junio C Hamano1-1/+2
"color.diff.plain" was a misnomer; give it 'color.diff.context' as a more logical synonym. * jk/color-diff-plain-is-context: diff.h: rename DIFF_PLAIN color slot to DIFF_CONTEXT diff: accept color.diff.context as a synonym for "plain"
2015-06-01Merge branch 'fm/fetch-raw-sha1'Libravatar Junio C Hamano1-2/+8
"git upload-pack" that serves "git fetch" can be told to serve commits that are not at the tip of any ref, as long as they are reachable from a ref, with uploadpack.allowReachableSHA1InWant configuration variable. * fm/fetch-raw-sha1: upload-pack: optionally allow fetching reachable sha1 upload-pack: prepare to extend allow-tip-sha1-in-want config.txt: clarify allowTipSHA1InWant with camelCase
2015-05-27diff: accept color.diff.context as a synonym for "plain"Libravatar Jeff King1-1/+2
The term "plain" is a bit ambiguous; let's allow the more specific "context", but keep "plain" around for compatibility. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-26Merge branch 'pt/pull-ff-vs-merge-ff'Libravatar Junio C Hamano1-1/+1
The pull.ff configuration was supposed to override the merge.ff configuration, but it didn't. * pt/pull-ff-vs-merge-ff: pull: parse pull.ff as a bool or string pull: make pull.ff=true override merge.ff
2015-05-22upload-pack: optionally allow fetching reachable sha1Libravatar Fredrik Medley1-0/+6
With uploadpack.allowReachableSHA1InWant configuration option set on the server side, "git fetch" can make a request with a "want" line that names an object that has not been advertised (likely to have been obtained out of band or from a submodule pointer). Only objects reachable from the branch tips, i.e. the union of advertised branches and branches hidden by transfer.hideRefs, will be processed. Note that there is an associated cost of having to walk back the history to check the reachability. This feature can be used when obtaining the content of a certain commit, for which the sha1 is known, without the need of cloning the whole repository, especially if a shallow fetch is used. Useful cases are e.g. repositories containing large files in the history, fetching only the needed data for a submodule checkout, when sharing a sha1 without telling which exact branch it belongs to and in Gerrit, if you think in terms of commits instead of change numbers. (The Gerrit case has already been solved through allowTipSHA1InWant as every Gerrit change has a ref.) Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22Merge branch 'mh/lockfile-retry'Libravatar Junio C Hamano1-0/+6
Instead of dying immediately upon failing to obtain a lock, retry after a short while with backoff. * mh/lockfile-retry: lock_packed_refs(): allow retries when acquiring the packed-refs lock lockfile: allow file locking to be retried with a timeout
2015-05-22Merge branch 'jk/asciidoc-markup-fix'Libravatar Junio C Hamano1-5/+5
Various documentation mark-up fixes to make the output more consistent in general and also make AsciiDoctor (an alternative formatter) happier. * jk/asciidoc-markup-fix: doc: convert AsciiDoc {?foo} to ifdef::foo[] doc: put example URLs and emails inside literal backticks doc: drop backslash quoting of some curly braces doc: convert \--option to --option doc/add: reformat `--edit` option doc: fix length of underlined section-title doc: fix hanging "+"-continuation doc: fix unquoted use of "{type}" doc: fix misrendering due to `single quote'
2015-05-22Merge branch 'ls/http-ssl-cipher-list'Libravatar Junio C Hamano1-0/+13
Introduce http.<url>.SSLCipherList configuration variable to tweak the list of cipher suite to be used with libcURL when talking with https:// sites. * ls/http-ssl-cipher-list: http: add support for specifying an SSL cipher list
2015-05-21config.txt: clarify allowTipSHA1InWant with camelCaseLibravatar Fredrik Medley1-2/+2
Most of the options in config.txt are camelCase. Improve the readability for allowtipsha1inwant by changing to allowTipSHA1InWant. Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-18pull: make pull.ff=true override merge.ffLibravatar Paul Tan1-1/+1
Since b814da8 (pull: add pull.ff configuration, 2014-01-15), running git-pull with the configuration pull.ff=false or pull.ff=only is equivalent to passing --no-ff and --ff-only to git-merge. However, if pull.ff=true, no switch is passed to git-merge. This leads to the confusing behavior where pull.ff=false or pull.ff=only is able to override merge.ff, while pull.ff=true is unable to. Fix this by adding the --ff switch if pull.ff=true, and add a test to catch future regressions. Furthermore, clarify in the documentation that pull.ff overrides merge.ff. Signed-off-by: Paul Tan <pyokagan@gmail.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-14lock_packed_refs(): allow retries when acquiring the packed-refs lockLibravatar Michael Haggerty1-0/+6
Currently, there is only one attempt to acquire any lockfile, and if the lock is held by another process, the locking attempt fails immediately. This is not such a limitation for loose reference files. First, they don't take long to rewrite. Second, most reference updates have a known "old" value, so if another process is updating a reference at the same moment that we are trying to lock it, then probably the expected "old" value will not longer be valid, and the update will fail anyway. But these arguments do not hold for packed-refs: * The packed-refs file can be large and take significant time to rewrite. * Many references are stored in a single packed-refs file, so it could be that the other process was changing a different reference than the one that we are interested in. Therefore, it is much more likely for there to be spurious lock conflicts in connection to the packed-refs file, resulting in unnecessary command failures. So, if the first attempt to lock the packed-refs file fails, continue retrying for a configurable length of time before giving up. The default timeout is 1 second. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-12doc: convert \--option to --optionLibravatar Jeff King1-5/+5
Older versions of AsciiDoc would convert the "--" in "--option" into an emdash. According to 565e135 (Documentation: quote double-dash for AsciiDoc, 2011-06-29), this is fixed in AsciiDoc 8.3.0. According to bf17126, we don't support anything older than 8.4.1 anyway, so we no longer need to worry about quoting. Even though this does not change the output at all, there are a few good reasons to drop the quoting: 1. It makes the source prettier to read. 2. We don't quote consistently, which may be confusing when reading the source. 3. Asciidoctor does not like the quoting, and renders a literal backslash. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-11Merge branch 'nd/multiple-work-trees'Libravatar Junio C Hamano1-0/+9
A replacement for contrib/workdir/git-new-workdir that does not rely on symbolic links and make sharing of objects and refs safer by making the borrowee and borrowers aware of each other. * nd/multiple-work-trees: (41 commits) prune --worktrees: fix expire vs worktree existence condition t1501: fix test with split index t2026: fix broken &&-chain t2026 needs procondition SANITY git-checkout.txt: a note about multiple checkout support for submodules checkout: add --ignore-other-wortrees checkout: pass whole struct to parse_branchname_arg instead of individual flags git-common-dir: make "modules/" per-working-directory directory checkout: do not fail if target is an empty directory t2025: add a test to make sure grafts is working from a linked checkout checkout: don't require a work tree when checking out into a new one git_path(): keep "info/sparse-checkout" per work-tree count-objects: report unused files in $GIT_DIR/worktrees/... gc: support prune --worktrees gc: factor out gc.pruneexpire parsing code gc: style change -- no SP before closing parenthesis checkout: clean up half-prepared directories in --to mode checkout: reject if the branch is already checked out elsewhere prune: strategies for linked checkouts checkout: support checking out into a new working directory ...
2015-05-08http: add support for specifying an SSL cipher listLibravatar Lars Kellogg-Stedman1-0/+13
Teach git about a new option, "http.sslCipherList", which permits one to specify a list of ciphers to use when negotiating SSL connections. The setting can be overwridden by the GIT_SSL_CIPHER_LIST environment variable. Signed-off-by: Lars Kellogg-Stedman <lars@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-23Merge branch 'jk/push-config'Libravatar Junio C Hamano1-0/+6
Restructure "git push" codepath to make it easier to add new configuration bits and then add push.followTags configuration that turns --follow-tags option on by default. * jk/push-config: push: allow --follow-tags to be set by config push.followTags cmd_push: pass "flags" pointer to config callback cmd_push: set "atomic" bit directly git_push_config: drop cargo-culted wt_status pointer
2015-03-23Merge branch 'nd/config-doc-camelCase'Libravatar Junio C Hamano1-121/+121
Documentation updates. * nd/config-doc-camelCase: *config.txt: stick to camelCase naming convention
2015-03-23Merge branch 'mg/doc-status-color-slot' into maintLibravatar Junio C Hamano1-2/+3
Documentation fixes. * mg/doc-status-color-slot: config,completion: add color.status.unmerged
2015-03-23Merge branch 'jc/decorate-leaky-separator-color' into maintLibravatar Junio C Hamano1-49/+75
"git log --decorate" did not reset colors correctly around the branch names. * jc/decorate-leaky-separator-color: log --decorate: do not leak "commit" color into the next item Documentation/config.txt: simplify boolean description in the syntax section Documentation/config.txt: describe 'color' value type in the "Values" section Documentation/config.txt: have a separate "Values" section Documentation/config.txt: describe the structure first and then meaning Documentation/config.txt: explain multi-valued variables once Documentation/config.txt: avoid unnecessary negation
2015-03-20Merge branch 'jc/decorate-leaky-separator-color'Libravatar Junio C Hamano1-49/+73
"git log --decorate" did not reset colors correctly around the branch names. * jc/decorate-leaky-separator-color: log --decorate: do not leak "commit" color into the next item Documentation/config.txt: simplify boolean description in the syntax section Documentation/config.txt: describe 'color' value type in the "Values" section Documentation/config.txt: have a separate "Values" section Documentation/config.txt: describe the structure first and then meaning Documentation/config.txt: explain multi-valued variables once Documentation/config.txt: avoid unnecessary negation
2015-03-20Merge branch 'nd/versioncmp-prereleases'Libravatar Junio C Hamano1-0/+12
The versionsort.prerelease configuration variable can be used to specify that v1.0-pre1 comes before v1.0. * nd/versioncmp-prereleases: config.txt: update versioncmp.prereleaseSuffix versionsort: support reorder prerelease suffixes
2015-03-17Merge branch 'mg/doc-status-color-slot'Libravatar Junio C Hamano1-2/+4
Documentation fixes. * mg/doc-status-color-slot: config,completion: add color.status.unmerged
2015-03-14push: allow --follow-tags to be set by config push.followTagsLibravatar Dave Olszewski1-0/+6
Signed-off-by: Dave Olszewski <cxreg@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-13Merge branch 'ms/submodule-update-config-doc' into maintLibravatar Junio C Hamano1-5/+9
The interaction between "git submodule update" and the submodule.*.update configuration was not clearly documented. * ms/submodule-update-config-doc: submodule: improve documentation of update subcommand
2015-03-13*config.txt: stick to camelCase naming conventionLibravatar Nguyễn Thái Ngọc Duy1-121/+121
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>
2015-03-10config,completion: add color.status.unmergedLibravatar Michael J Gruber1-2/+4
Reported-by: "Mladen B." <mladen074@gmail.com> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-10config.txt: update versioncmp.prereleaseSuffixLibravatar Nguyễn Thái Ngọc Duy1-2/+7
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-06Merge branch 'ms/submodule-update-config-doc'Libravatar Junio C Hamano1-5/+9
The interaction between "git submodule update" and the submodule.*.update configuration was not clearly documented. * ms/submodule-update-config-doc: submodule: improve documentation of update subcommand
2015-03-06Merge branch 'mm/am-c-doc' into maintLibravatar Junio C Hamano1-0/+7
The configuration variable 'mailinfo.scissors' was hard to discover in the documentation. * mm/am-c-doc: Documentation/git-am.txt: mention mailinfo.scissors config variable Documentation/config.txt: document mailinfo.scissors
2015-03-05Merge branch 'jc/conf-var-doc' into maintLibravatar Junio C Hamano1-8/+7
Longstanding configuration variable naming rules has been added to the documentation. * jc/conf-var-doc: CodingGuidelines: describe naming rules for configuration variables config.txt: mark deprecated variables more prominently config.txt: clarify that add.ignore-errors is deprecated
2015-03-05Merge branch 'mm/am-c-doc'Libravatar Junio C Hamano1-0/+7
The configuration variable 'mailinfo.scissors' was hard to discover in the documentation. * mm/am-c-doc: Documentation/git-am.txt: mention mailinfo.scissors config variable Documentation/config.txt: document mailinfo.scissors
2015-03-04log --decorate: do not leak "commit" color into the next itemLibravatar Junio C Hamano1-0/+7
In "git log --decorate", you would see the commit header like this: commit ... (HEAD, jc/decorate-leaky-separator-color) where "commit ... (" is painted in color.diff.commit, "HEAD" in color.decorate.head, ", " in color.diff.commit, the branch name in color.decorate.branch and then closing ")" in color.diff.commit. If you wanted to paint the HEAD and local branch name in the same color as the body text (perhaps because cyan and green are too faint on a black-on-white terminal to be readable), you would not want to have to say [color "decorate"] head = black branch = black because that you would not be able to reuse same configuration on a white-on-black terminal. You would naively expect [color "decorate"] head = normal branch = normal to work, but unfortunately it does not. It paints the string "HEAD" and the branch name in the same color as the opening parenthesis or comma between the decoration elements. This is because the code forgets to reset the color after printing the "prefix" in its own color. It theoretically is possible that some people were expecting and relying on that the attribute set as the "diff.commit" color, which is used to draw these opening parenthesis and inter-item comma, is inherited by the drawing of branch names, but it is not how the coloring works everywhere else. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-04Documentation/config.txt: simplify boolean description in the syntax sectionLibravatar Junio C Hamano1-2/+2
The 'true' short-hand doesn't deserve a separate sentence; even our own git config --bool foo.bar yes would not produce it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-04Documentation/config.txt: describe 'color' value type in the "Values" sectionLibravatar Junio C Hamano1-16/+13
Instead of describing it for color.branch.<slot> and have everybody else refer to it, explain how colors are spelled in "Values" section upfront. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-04Documentation/config.txt: have a separate "Values" sectionLibravatar Junio C Hamano1-8/+31
The various types of values set to the configuration variables deserve more than a brief footnote mention in the syntax section, and it will be more so after the later steps of this clean up effort. Move the mention of booleans from the syntax section to this new section, and describe how human-readble integers can be spelled with scaling there. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-04Documentation/config.txt: describe the structure first and then meaningLibravatar Junio C Hamano1-16/+15
A line can be continued via a backquote-LF and can be chomped at a comment character. But that is not specific to string-typed values. It is common to all, just like unquoted leading and trailing whitespaces are stripped and inter-word spacing are retained. Move the description around and desribe these structural rules first, then introduce the double-quote facility as a way to override them, and finally mention various types of values. Note that these structural rules only apply to the value part of the configuration file. E.g. [aSection] \ name \ = value does not work, because the rules kick in only after seeing "name =". Both the original and the updated text are phrased in an awkward way by singling out the "value" part of the line because of this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-04Documentation/config.txt: explain multi-valued variables onceLibravatar Junio C Hamano1-4/+3
The syntax section repeats what the preamble explained already. That a variable can have multiple values is more about what a variable is than the syntax of the file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-04Documentation/config.txt: avoid unnecessary negationLibravatar Junio C Hamano1-3/+3
Section names and variable names are both case-insensitive, but one is described as "not case sensitive". Use "case-insensitive" for both. Instead of saying "... have to be escaped" without telling what that escaping achieves, state it in a more positive way, i.e. "... can be included by escaping". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-02submodule: improve documentation of update subcommandLibravatar Michal Sojka1-5/+9
The documentation of 'git submodule update' has several problems: 1) It mentions that value 'none' of submodule.$name.update can be overridden by --checkout, but other combinations of configuration values and command line options are not mentioned. 2) The documentation of submodule.$name.update is scattered across three places, which is confusing. 3) The documentation of submodule.$name.update in gitmodules.txt is incorrect, because the code always uses the value from .git/config and never from .gitmodules. 4) Documentation of --force was incomplete, because it is only effective in case of checkout method of update. Fix all these problems by documenting submodule.*.update in git-submodule.txt and make everybody else refer to it. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-27versionsort: support reorder prerelease suffixesLibravatar Nguyễn Thái Ngọc Duy1-0/+7
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-22Merge branch 'jc/conf-var-doc'Libravatar Junio C Hamano1-8/+7
Longstanding configuration variable naming rules has been added to the documentation. * jc/conf-var-doc: CodingGuidelines: describe naming rules for configuration variables config.txt: mark deprecated variables more prominently config.txt: clarify that add.ignore-errors is deprecated
2015-02-20Documentation/config.txt: document mailinfo.scissorsLibravatar Matthieu Moy1-0/+7
The variable was documented in git-mailinfo.txt, but not in config.txt. The detailed documentation is still the one of --scissors in git-mailinfo.txt, but we give enough information here to let the user understand what it is about, and to make it easy to find it (e.g. searching ">8" and "8<" finds it). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-11Merge branch 'jc/push-to-checkout'Libravatar Junio C Hamano1-1/+5
Extending the js/push-to-deploy topic, the behaviour of "git push" when updating the working tree and the index with an update to the branch that is checked out can be tweaked by push-to-checkout hook. * jc/push-to-checkout: receive-pack: support push-to-checkout hook receive-pack: refactor updateInstead codepath
2015-02-11Merge branch 'sb/atomic-push'Libravatar Junio C Hamano1-0/+5
"git push" has been taught a "--atomic" option that makes push to update more than one ref an "all-or-none" affair. * sb/atomic-push: Document receive.advertiseatomic t5543-atomic-push.sh: add basic tests for atomic pushes push.c: add an --atomic argument send-pack.c: add --atomic command line argument send-pack: rename ref_update_to_be_sent to check_to_send_update receive-pack.c: negotiate atomic push support receive-pack.c: add execute_commands_atomic function receive-pack.c: move transaction handling in a central place receive-pack.c: move iterating over all commands outside execute_commands receive-pack.c: die instead of error in case of possible future bug receive-pack.c: shorten the execute_commands loop over all commands
2015-01-28config.txt: mark deprecated variables more prominentlyLibravatar Junio C Hamano1-4/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-28config.txt: clarify that add.ignore-errors is deprecatedLibravatar Junio C Hamano1-5/+4
The old text gave an impression that even in a new repository using old form might be safer. Only Git from pre 1.7.0 days choke on the correctly named variable, which is ancient by today's standard. We have no intention to remove the support for deprecated ones, but let's make sure that we do not give room for confused questions such as "why does core.sparse-checkout not work, when add.ignore-errors does?" Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-14Merge branch 'po/doc-core-ignorestat'Libravatar Junio C Hamano1-8/+13
* po/doc-core-ignorestat: doc: core.ignoreStat update, and clarify the --assume-unchanged effect doc: core.ignoreStat clarify the --assume-unchanged effect
2015-01-14Document receive.advertiseatomicLibravatar Stefan Beller1-0/+5
This was missing in 1b70fe5d3054 (2015-01-07, receive-pack.c: negotiate atomic push support) as I squashed the option in very late in the patch series. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-12doc: core.ignoreStat update, and clarify the --assume-unchanged effectLibravatar Philip Oakley1-9/+13
The assume-unchanged bit, and consequently core.ignoreStat, can be misunderstood. Be assertive about the expectation that file changes should notified to Git. Overhaul the general wording thus: 1. direct description of what is ignored given first. 2. example instruction of the user manual action required. 3. use sideways indirection for assume-unchanged and update-index references. 4. add a 'normally' to give leeway for the change detection. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-08receive-pack: support push-to-checkout hookLibravatar Junio C Hamano1-1/+5
When receive.denyCurrentBranch is set to updateInstead, a push that tries to update the branch that is currently checked out is accepted only when the index and the working tree exactly matches the currently checked out commit, in which case the index and the working tree are updated to match the pushed commit. Otherwise the push is refused. This hook can be used to customize this "push-to-deploy" logic. The hook receives the commit with which the tip of the current branch is going to be updated, and can decide what kind of local changes are acceptable and how to update the index and the working tree to match the updated tip of the current branch. For example, the hook can simply run `git read-tree -u -m HEAD "$1"` in order to emulate 'git fetch' that is run in the reverse direction with `git push`, as the two-tree form of `read-tree -u -m` is essentially the same as `git checkout` that switches branches while keeping the local changes in the working tree that do not interfere with the difference between the branches. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-07Merge branch 'lh/send-email-hide-x-mailer'Libravatar Junio C Hamano1-0/+1
"git send-email" normally identifies itself via X-Mailer: header in the message it sends out. A new command line flag allows the user to squelch the header. * lh/send-email-hide-x-mailer: test/send-email: --[no-]xmailer tests send-email: add --[no-]xmailer option