summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
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-23Merge branch 'km/imap-send-libcurl-options' into maintLibravatar Junio C Hamano1-1/+2
"git imap-send" learned to optionally talk with an IMAP server via libcURL; because there is no other option when Git is built with NO_OPENSSL option, use that codepath by default under such configuration. * km/imap-send-libcurl-options: imap-send: use cURL automatically when NO_OPENSSL defined
2015-03-13Git 2.3.3Libravatar Junio C Hamano2-1/+41
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-13Merge branch 'mr/doc-clean-f-f' into maintLibravatar Junio C Hamano1-2/+6
Documentation update. * mr/doc-clean-f-f: Documentation/git-clean.txt: document that -f may need to be given twice
2015-03-13Merge branch 'mg/doc-remote-tags-or-not' into maintLibravatar Junio C Hamano1-0/+3
"git remote add" mentioned "--tags" and "--no-tags" and was not clear that fetch from the remote in the future will use the default behaviour when neither is given to override it. * mg/doc-remote-tags-or-not: git-remote.txt: describe behavior without --tags and --no-tags
2015-03-13Merge branch 'ms/submodule-update-config-doc' into maintLibravatar Junio C Hamano3-37/+64
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-13Merge branch 'jc/apply-beyond-symlink' into maintLibravatar Junio C Hamano1-1/+11
"git apply" was not very careful about reading from, removing, updating and creating paths outside the working tree (under --index/--cached) or the current directory (when used as a replacement for GNU patch). * jc/apply-beyond-symlink: apply: do not touch a file beyond a symbolic link apply: do not read from beyond a symbolic link apply: do not read from the filesystem under --index apply: reject input that touches outside the working area
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-10imap-send: use cURL automatically when NO_OPENSSL definedLibravatar Kyle J. McKay1-1/+2
If both USE_CURL_FOR_IMAP_SEND and NO_OPENSSL are defined do not force the user to add --curl to get a working git imap-send command. Instead automatically select --curl and warn and ignore the --no-curl option. And while we're in there, correct the warning message when --curl is requested but not supported. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-06Git 2.3.2Libravatar Junio C Hamano2-1/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-06Merge branch 'mm/am-c-doc' into maintLibravatar Junio C Hamano2-1/+9
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-05Prepare for 2.3.2Libravatar Junio C Hamano1-0/+68
2015-03-05Merge branch 'jc/conf-var-doc' into maintLibravatar Junio C Hamano2-8/+30
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 'jc/remote-set-url-doc' into maintLibravatar Junio C Hamano1-6/+14
Clarify in the documentation that "remote.<nick>.pushURL" and "remote.<nick>.URL" are there to name the same repository accessed via different transports, not two separate repositories. * jc/remote-set-url-doc: Documentation/git-remote.txt: stress that set-url is not for triangular
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 Sojka3-37/+64
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-03-02git-remote.txt: describe behavior without --tags and --no-tagsLibravatar Michael J Gruber1-0/+3
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-26Documentation/git-clean.txt: document that -f may need to be given twiceLibravatar Mikko Rapeli1-2/+6
This is needed in build automation where the tree really needs to be reset to known state. Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-24Git 2.3.1Libravatar Junio C Hamano2-1/+54
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-24Merge branch 'jc/doc-log-rev-list-options' into maintLibravatar Junio C Hamano1-5/+7
"git log --help" used to show rev-list options that are irrelevant to the "log" command. * jc/doc-log-rev-list-options: Documentation: what does "git log --indexed-objects" even mean?
2015-02-24Merge branch 'jc/diff-format-doc' into maintLibravatar Junio C Hamano1-1/+2
The documentation incorrectly said that C(opy) and R(ename) are the only ones that can be followed by the score number in the output in the --raw format. * jc/diff-format-doc: diff-format doc: a score can follow M for rewrite
2015-02-24Merge branch 'mg/push-repo-option-doc' into maintLibravatar Junio C Hamano1-16/+2
The "git push" documentation made the "--repo=<there>" option easily misunderstood. * mg/push-repo-option-doc: git-push.txt: document the behavior of --repo
2015-02-20Documentation/git-am.txt: mention mailinfo.scissors config variableLibravatar Matthieu Moy1-1/+2
It was already documented, but the user had to follow the link to git-mailinfo.txt to find it. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-10apply: reject input that touches outside the working areaLibravatar Junio C Hamano1-1/+11
By default, a patch that affects outside the working area (either a Git controlled working tree, or the current working directory when "git apply" is used as a replacement of GNU patch) is rejected as a mistake (or a mischief). Git itself does not create such a patch, unless the user bends over backwards and specifies a non-standard prefix to "git diff" and friends. When `git apply` is used as a "better GNU patch", the user can pass the `--unsafe-paths` option to override this safety check. This option has no effect when `--index` or `--cached` is in use. The new test was stolen from Jeff King with slight enhancements. Note that a few new tests for touching outside the working area by following a symbolic link are still expected to fail at this step, but will be fixed in later steps. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-05Git 2.3Libravatar Junio C Hamano2-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-02CodingGuidelines: describe naming rules for configuration variablesLibravatar Junio C Hamano1-0/+23
We may want to say something about command line option names in the new section as well, but for now, let's make sure everybody is clear on how to structure and name their configuration variables. The text for the rules are partly taken from the log message of Jonathan's 6b3020a2 (add: introduce add.ignoreerrors synonym for add.ignore-errors, 2010-12-01). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29Documentation/git-remote.txt: stress that set-url is not for triangularLibravatar Junio C Hamano1-6/+14
It seems to be a common mistake to try using a single remote (e.g. 'origin') to fetch from one place (i.e. upstream) while pushing to another (i.e. your publishing point). That will never work satisfactorily, and it is easy to understand why if you think about what refs/remotes/origin/* would mean in such a world. It fundamentally cannot reflect the reality. If it follows the state of your upstream, it cannot match what you have published, and vice versa. It may be that misinformation is spread by some people. Let's counter them by adding a few words to our documentation. - The description was referring to <oldurl> and <newurl>, but never mentioned <name> argument you give from the command line. By mentioning "remote <name>", stress the fact that it is configuring a single remote. - Add a reminder that explicitly states that this is about a single remote, which the triangular workflow is not about. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-28diff-format doc: a score can follow M for rewriteLibravatar Junio C Hamano1-1/+2
b6d8f309 (diff-raw format update take #2., 2005-05-23) started documenting the diff format, and it said ... (8) sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree". (9) status, followed by similarlity index number only for C and R. (10) a tab or a NUL when '-z' option is used. ... because C and R _were_ the only ones that came with a number back then. This was corrected by ddafa7e9 (diff-helper: Fix R/C score parsing under -z flag., 2005-05-29) and we started saying "score" instead of "similarlity index" (because we can have other kind of score there), and stopped saying "only for C and R" (because Git is an ever evolving system). Later f345b0a0 (Add -B flag to diff-* brothers., 2005-05-30) introduced a new concept, "dissimilarity" score; it did not have to fix any documentation. The current text that says only C and R can have scores came independently from a5a323f3 (Add reference for status letters in documentation., 2008-11-02) and it was wrong from the day one. Noticed-by: Mike Hommey Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-28git-push.txt: document the behavior of --repoLibravatar Michael J Gruber1-16/+2
As per the code, the --repo <repo> option is equivalent to the <repo> argument to 'git push', but somehow it was documented as something that is more than that. [It exists for historical reasons, back from the time when options had to come before arguments.] Say so. [But not that.] Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-23Documentation: what does "git log --indexed-objects" even mean?Libravatar Junio C Hamano1-5/+7
4fe10219 (rev-list: add --indexed-objects option, 2014-10-16) adds "--indexed-objects" option to "rev-list", and it is only useful in the context of "git rev-list" and not "git log". There are other object traversal options that do not make sense for "git log" that are shown in the manual page. Move the description of "--indexed-objects" to the object traversal section so that it sits together with its friends "--objects", "--objects-edge", etc. and then show them only in "git rev-list" documentation. Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-22Merge branch 'sh/asciidoc-git-version-fix'Libravatar Junio C Hamano1-1/+1
* sh/asciidoc-git-version-fix: Documentation: fix version numbering
2015-01-22Documentation: fix version numberingLibravatar Sven van Haastregt1-1/+1
Version numbers in asciidoc-generated content (such as man pages) went missing as of da8a366 (Documentation: refactor common operations into variables). Fix by putting the underscore back in the variable name. Signed-off-by: Sven van Haastregt <svenvh@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-20Git 2.3.0-rc1Libravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-14Fifth batch for 2.3 cycleLibravatar Junio C Hamano1-2/+27
Hopefully this will be the final feature update for 2.3-rc1 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-14Merge branch 'ak/doc-add-v-n-options'Libravatar Junio C Hamano1-1/+1
* ak/doc-add-v-n-options: Documentation: list long options for -v and -n
2015-01-14Merge branch 'aw/doc-smtp-ssl-cert-path'Libravatar Junio C Hamano1-4/+9
A long overdue documentation update to match an age-old code update. * aw/doc-smtp-ssl-cert-path: correct smtp-ssl-cert-path description
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-12Git 2.3.0-rc0Libravatar Junio C Hamano1-0/+17
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-12Sync with 2.2.2Libravatar Junio C Hamano2-1/+32