summaryrefslogtreecommitdiff
path: root/Documentation/git.txt
AgeCommit message (Collapse)AuthorFilesLines
2021-02-18git.txt: fix monospace renderingLibravatar Martin Ågren1-1/+1
When we write `<name>`s with the "s" tucked on to the closing backtick, we end up rendering the backticks literally. Rephrase this sentence slightly to render this as monospace. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-25Merge branch 'ps/config-env-pairs'Libravatar Junio C Hamano1-1/+23
Introduce two new ways to feed configuration variable-value pairs via environment variables, and tweak the way GIT_CONFIG_PARAMETERS encodes variable/value pairs to make it more robust. * ps/config-env-pairs: config: allow specifying config entries via envvar pairs environment: make `getenv_safe()` a public function config: store "git -c" variables using more robust format config: parse more robust format in GIT_CONFIG_PARAMETERS config: extract function to parse config pairs quote: make sq_dequote_step() a public function config: add new way to pass config via `--config-env` git: add `--super-prefix` to usage string
2021-01-12config: add new way to pass config via `--config-env`Libravatar Patrick Steinhardt1-1/+23
While it's already possible to pass runtime configuration via `git -c <key>=<value>`, it may be undesirable to use when the value contains sensitive information. E.g. if one wants to set `http.extraHeader` to contain an authentication token, doing so via `-c` would trivially leak those credentials via e.g. ps(1), which typically also shows command arguments. To enable this usecase without leaking credentials, this commit introduces a new switch `--config-env=<key>=<envvar>`. Instead of directly passing a value for the given key, it instead allows the user to specify the name of an environment variable. The value of that variable will then be used as value of the key. Co-authored-by: Jeff King <peff@peff.net> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-22git.txt: fix typos in 'linkgit' macro invocationLibravatar Philippe Blain1-2/+2
The 'linkgit' Asciidoc macro is misspelled as 'linkit' in the description of 'GIT_SEQUENCE_EDITOR' since the addition of that variable to git(1) in 902a126eca (doc: mention GIT_SEQUENCE_EDITOR and 'sequence.editor' more, 2020-08-31). Also, it uses two colons instead of one. Fix that. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-09refs: add GIT_TRACE_REFS debugging mechanismLibravatar Han-Wen Nienhuys1-0/+4
When set in the environment, GIT_TRACE_REFS makes git print operations and results as they flow through the ref storage backend. This helps debug discrepancies between different ref backends. Example: $ GIT_TRACE_REFS="1" ./git branch 15:42:09.769631 refs/debug.c:26 ref_store for .git 15:42:09.769681 refs/debug.c:249 read_raw_ref: HEAD: 0000000000000000000000000000000000000000 (=> refs/heads/ref-debug) type 1: 0 15:42:09.769695 refs/debug.c:249 read_raw_ref: refs/heads/ref-debug: 3a238e539bcdfe3f9eb5010fd218640c1b499f7a (=> refs/heads/ref-debug) type 0: 0 15:42:09.770282 refs/debug.c:233 ref_iterator_begin: refs/heads/ (0x1) 15:42:09.770290 refs/debug.c:189 iterator_advance: refs/heads/b4 (0) 15:42:09.770295 refs/debug.c:189 iterator_advance: refs/heads/branch3 (0) Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-03Merge branch 'pb/doc-external-diff-env'Libravatar Junio C Hamano1-2/+3
Doc update. * pb/doc-external-diff-env: git.txt: correct stale 'GIT_EXTERNAL_DIFF' description
2020-09-01git.txt: correct stale 'GIT_EXTERNAL_DIFF' descriptionLibravatar Philippe Blain1-2/+3
In fde97d8ac6 (Update documentation to remove incorrect GIT_DIFF_OPTS example., 2006-11-27), the description of the 'GIT_EXTERNAL_DIFF' variable was moved from 'diff-format.txt' to 'git.txt', and the documentation was updated to remove a 'diff(1)' invocation since Git did not use an external diff program anymore by default. However, the description of 'GIT_EXTERNAL_DIFF' still mentions "instead of the diff invocation described above", which is confusing. Correct that outdated sentence. Also, link to git(1) in 'diff-generate-patch.txt' when GIT_DIFF_OPTS and GIT_EXTERNAL_DIFF are mentioned, so that users can easily know what these variables are about. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-31doc: mention GIT_SEQUENCE_EDITOR and 'sequence.editor' moreLibravatar Philippe Blain1-0/+6
The environment variable `GIT_SEQUENCE_EDITOR`, and the configuration variable 'sequence.editor', which were added in 821881d88d ("rebase -i": support special-purpose editor to edit insn sheet, 2011-10-17), are mentioned in the `git config` man page but not anywhere else. Include `config/sequencer.txt` in `git-rebase.txt`, so that both the environment variable and the configuration setting are mentioned there. Also, add `GIT_SEQUENCE_EDITOR` to the list of environment variables in `git(1)`. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-24Merge branch 'ma/doc-sha-256-is-experimental'Libravatar Junio C Hamano1-1/+2
The recent addition of SHA-256 support is marked as experimental in the documentation. * ma/doc-sha-256-is-experimental: Documentation: mark `--object-format=sha256` as experimental
2020-08-17Documentation: mark `--object-format=sha256` as experimentalLibravatar Martin Ågren1-1/+2
After eff45daab8 ("repository: enable SHA-256 support by default", 2020-07-29), vanilla builds of Git enable the user to run, e.g., git init --object-format=sha256 and hack away. This can be a good way to gain experience with the SHA-256 world, e.g., to find bugs that GIT_TEST_DEFAULT_HASH=sha256 make test doesn't spot. But it really is a separate world: Such SHA-256 repos will live entirely separate from the (by now fairly large) set of SHA-1 repos. Interacting across the border is possible in principle, e.g., through "diff + apply" (or "format-patch + am"), but even that has its limitations: Applying a SHA-256 diff in a SHA-1 repo works in the simple case, but if you need to resort to `-3`, you're out of luck. Similarly, "push + pull" should work, but you really will be operating mostly offset from the rest of the world. That might be ok by the time you initialize your repository, and it might be ok for several months after that, but there might come a day when you're starting to regret your use of `git init --object-format=sha256` and have dug yourself into a fairly deep hole. There are currently topics in flight to document our data formats and protocols regarding SHA-256 and in some cases (midx and commit-graph), we're considering adjusting how the file formats indicate which object format to use. Wherever `--object-format` is mentioned in our documentation, let's make it clear that using it with "sha256" is experimental. If we later need to explain why we can't handle data we generated back in 2020, we can always point to this paragraph we're adding here. By "include::"-ing a small blurb, we should be able to be consistent throughout the documentation and can eventually gradually tone down the severity of this text. One day, we might even use it to start phasing out `--object-format=sha1`, but let's not get ahead of ourselves... There's also `extensions.objectFormat`, but it's only mentioned three times. Twice where we're adding this new disclaimer and in the third spot we already have a "do not edit" warning. From there, interested readers should eventually find this new one that we're adding here. Because `GIT_DEFAULT_HASH` provides another entry point to this functionality, document the experimental nature of it too. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-04git.txt: add list of guidesLibravatar Philippe Blain1-0/+7
Not all man5/man7 guides are mentioned in the 'git(1)' documentation, which makes the missing ones somewhat hard to find. Add a list of the guides to git(1) by leveraging the existing `Documentation/cmd-list.perl` script to generate a file `cmds-guide.txt` which gets included in git.txt. Also, do not hard-code the manual section '1'. Instead, use a regex so that the manual section is discovered from the first line of each `git*.txt` file. This addition was hinted at in 1b81d8cb19 (help: use command-list.txt for the source of guides, 2018-05-20). Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22Merge branch 'jt/redact-all-cookies'Libravatar Junio C Hamano1-5/+4
The interface to redact sensitive information in the trace output has been simplified. * jt/redact-all-cookies: http: redact all cookies, teach GIT_TRACE_REDACT=0
2020-06-08Merge branch 'jt/curl-verbose-on-trace-curl'Libravatar Junio C Hamano1-2/+0
Rewrite support for GIT_CURL_VERBOSE in terms of GIT_TRACE_CURL. Looking good. * jt/curl-verbose-on-trace-curl: http, imap-send: stop using CURLOPT_VERBOSE t5551: test that GIT_TRACE_CURL redacts password
2020-06-05http: redact all cookies, teach GIT_TRACE_REDACT=0Libravatar Jonathan Tan1-5/+4
In trace output (when GIT_TRACE_CURL is true), redact the values of all HTTP cookies by default. Now that auth headers (since the implementation of GIT_TRACE_CURL in 74c682d3c6 ("http.c: implement the GIT_TRACE_CURL environment variable", 2016-05-24)) and cookie values (since this commit) are redacted by default in these traces, also allow the user to inhibit these redactions through an environment variable. Since values of all cookies are now redacted by default, GIT_REDACT_COOKIES (which previously allowed users to select individual cookies to redact) now has no effect. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-27Documentation: correct hash environment variableLibravatar Toon Claes1-1/+1
To set the default hash algorithm you can set the `GIT_DEFAULT_HASH` environment variable. In the documentation this variable is named `GIT_DEFAULT_HASH_ALGORITHM`, which is incorrect. Signed-off-by: Toon Claes <toon@iotcl.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-11http, imap-send: stop using CURLOPT_VERBOSELibravatar Jonathan Tan1-2/+0
Whenever GIT_CURL_VERBOSE is set, teach Git to behave as if GIT_TRACE_CURL=1 and GIT_TRACE_CURL_NO_DATA=1 is set, instead of setting CURLOPT_VERBOSE. This is to prevent inadvertent revelation of sensitive data. In particular, GIT_CURL_VERBOSE redacts neither the "Authorization" header nor any cookies specified by GIT_REDACT_COOKIES. Unifying the tracing mechanism also has the future benefit that any improvements to the tracing mechanism will benefit both users of GIT_CURL_VERBOSE and GIT_TRACE_CURL, and we do not need to remember to implement any improvement twice. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-24builtin/init-db: add environment variable for new repo hashLibravatar brian m. carlson1-0/+6
For the foreseeable future, SHA-1 will be the default algorithm for Git. However, when running the testsuite, we want to be able to test an arbitrary algorithm. It would be quite burdensome and very untidy to have to specify the algorithm we'd like to test every time we initialized a new repository somewhere in the testsuite, so add an environment variable to allow us to specify the default hash algorithm for Git. This has the benefit that we can set it once for the entire testsuite and not have to think about it. In the future, users can also use it to set the default for their repositories if they would like to do so. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-12Merge branch 'hw/doc-git-dir'Libravatar Junio C Hamano1-3/+17
One effect of specifying where the GIT_DIR is (either with the environment variable, or with the "git --git-dir=<where> cmd" option) is to disable the repository discovery. This has been placed a bit more stress in the documentation, as new users often get confused. * hw/doc-git-dir: git: update documentation for --git-dir
2020-01-30git: update documentation for --git-dirLibravatar Heba Waly1-3/+17
git --git-dir <path> is a bit confusing and sometimes doesn't work as the user would expect it to. For example, if the user runs `git --git-dir=<path> status`, git will skip the repository discovery algorithm and will assign the work tree to the user's current work directory unless otherwise specified. When this assignment is wrong, the output will not match the user's expectations. This patch updates the documentation to make it clearer. Signed-off-by: Heba Waly <heba.waly@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-22doc: move author and committer information to git-commit(1)Libravatar brian m. carlson1-2/+25
While at one time it made perfect sense to store information about configuring author and committer information in the documentation for git commit-tree, in modern Git that operation is seldom used. Most users will use git commit and expect to find comprehensive documentation about its use in the manual page for that command. Considering that there is significant confusion about how one is to use the user.name and user.email variables, let's put as much documentation as possible into an obvious place where users will be more likely to find it. In addition, expand the environment variables section to describe their use more fully. Even though we now describe all of the options there and in the configuration settings documentation, preserve the existing text in git-commit.txt so that people can easily reason about the ordering of the various options they can use. Explain the use of the author.* and committer.* options as well. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-10Merge branch 'ds/commit-graph-delay-gen-progress'Libravatar Junio C Hamano1-0/+4
One kind of progress messages were always given during commit-graph generation, instead of following the "if it takes more than two seconds, show progress" pattern, which has been corrected. * ds/commit-graph-delay-gen-progress: commit-graph: use start_delayed_progress() progress: create GIT_PROGRESS_DELAY
2019-12-06Merge branch 'jk/lore-is-the-archive'Libravatar Junio C Hamano1-1/+1
Doc update for the mailing list archiving and nntp service. * jk/lore-is-the-archive: doc: replace public-inbox links with lore.kernel.org doc: recommend lore.kernel.org over public-inbox.org
2019-11-30doc: recommend lore.kernel.org over public-inbox.orgLibravatar Jeff King1-1/+1
Since lore.kernel.org now has the same archive as public-inbox.org and may have more longevity going forward[1], let's recommend people use it for finding or referencing messages. [1] https://public-inbox.org/git/20191120195556.GA25189@dcvr/ or if you like: https://lore.kernel.org/git/20191120195556.GA25189@dcvr/ Signed-off-by: Jeff King <peff@peff.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-27progress: create GIT_PROGRESS_DELAYLibravatar Derrick Stolee1-0/+4
The start_delayed_progress() method is a preferred way to show optional progress to users as it ignores steps that take less than two seconds. However, this makes testing unreliable as tests expect to be very fast. In addition, users may want to decrease or increase this time interval depending on their preferences for terminal noise. Create the GIT_PROGRESS_DELAY environment variable to control the delay set during start_delayed_progress(). Set the value in some tests to guarantee their output remains consistent. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-07Documentation: fix a bunch of typos, both old and newLibravatar Elijah Newren1-2/+2
Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-11Merge branch 'sg/git-C-empty-doc'Libravatar Junio C Hamano1-1/+2
Doc update. * sg/git-C-empty-doc: Document that 'git -C ""' works and doesn't change directory
2019-07-09Merge branch 'nd/switch-and-restore'Libravatar Junio C Hamano1-0/+20
Two new commands "git switch" and "git restore" are introduced to split "checking out a branch to work on advancing its history" and "checking out paths out of the index and/or a tree-ish to work on advancing the current history" out of the single "git checkout" command. * nd/switch-and-restore: (46 commits) completion: disable dwim on "git switch -d" switch: allow to switch in the middle of bisect t2027: use test_must_be_empty Declare both git-switch and git-restore experimental help: move git-diff and git-reset to different groups doc: promote "git restore" user-manual.txt: prefer 'merge --abort' over 'reset --hard' completion: support restore t: add tests for restore restore: support --patch restore: replace --force with --ignore-unmerged restore: default to --source=HEAD when only --staged is specified restore: reject invalid combinations with --staged restore: add --worktree and --staged checkout: factor out worktree checkout code restore: disable overlay mode by default restore: make pathspec mandatory restore: take tree-ish from --source option instead checkout: split part of it to new command 'restore' doc: promote "git switch" ...
2019-07-01Document that 'git -C ""' works and doesn't change directoryLibravatar SZEDER Gábor1-1/+2
It's been behaving so since 6a536e2076 (git: treat "git -C '<path>'" as a no-op when <path> is empty, 2015-03-06). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-17Merge branch 'po/git-help-on-git-itself'Libravatar Junio C Hamano1-1/+2
"git help git" was hard to discover (well, at least for some people). * po/git-help-on-git-itself: Doc: git.txt: remove backticks from link and add git-scm.com/docs git.c: show usage for accessing the git(1) help page
2019-05-28trace2: document the supported values of GIT_TRACE2* env variablesLibravatar SZEDER Gábor1-8/+35
The descriptions of the GIT_TRACE2* environment variables link to the technical docs for further details on the supported values. However, a link like this only really works if the docs are viewed in a browser and the full documentation is available. OTOH, in 'man git' there are no links to conveniently click on, and distro-shipped git packages tend to include only the man pages, while the technical docs and the docs in html format are in a separate 'git-doc' package. So let's describe the supported values to make the manpage more self-contained, but still keep the references to the technical docs because the details of the SID, and the JSON and perf output formats are definitely beyond the scope of 'man git'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28trace2: rename environment variables to GIT_TRACE2*Libravatar SZEDER Gábor1-7/+7
For an environment variable that is supposed to be set by users, the GIT_TR2* env vars are just too unclear, inconsistent, and ugly. Most of the established GIT_* environment variables don't use abbreviations, and in case of the few that do (GIT_DIR, GIT_COMMON_DIR, GIT_DIFF_OPTS) it's quite obvious what the abbreviations (DIR and OPTS) stand for. But what does TR stand for? Track, traditional, trailer, transaction, transfer, transformation, transition, translation, transplant, transport, traversal, tree, trigger, truncate, trust, or ...?! The trace2 facility, as the '2' suffix in its name suggests, is supposed to eventually supercede Git's original trace facility. It's reasonable to expect that the corresponding environment variables follow suit, and after the original GIT_TRACE variables they are called GIT_TRACE2; there is no such thing is 'GIT_TR'. All trace2-specific config variables are, very sensibly, in the 'trace2' section, not in 'tr2'. OTOH, we don't gain anything at all by omitting the last three characters of "trace" from the names of these environment variables. So let's rename all GIT_TR2* environment variables to GIT_TRACE2*, before they make their way into a stable release. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-16Doc: git.txt: remove backticks from link and add git-scm.com/docsLibravatar Philip Oakley1-1/+2
While checking the html formatted git(1) manual page, it was noted that the link to https://git.github.io/htmldocs/git.html was formatted as code. Remove the backticks. While at it, add the https://git-scm.com/docs link which one reviewer noted had linkable section headings. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13trace2: add variable description to git.txtLibravatar Derrick Stolee1-0/+21
Documentation/technical/api-trace2.txt contains the full details of the trace2 API and the GIT_TR2* environment variables. However, most environment variables are included in Documentation/git.txt, including the GIT_TRACE* variables. Add a brief description of the GIT_TR2* variables with links to the full technical details. The biggest difference from the original variables is that we can specify a Unix Domain Socket. Mention this difference, but leave the details to the technical documents. Reported-by: Szeder Gábor <szeder.dev@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-07checkout: split part of it to new command 'restore'Libravatar Nguyễn Thái Ngọc Duy1-0/+20
Previously the switching branch business of 'git checkout' becomes a new command 'switch'. This adds the restore command for the checking out paths path. Similar to git-switch, a new man page is added to describe what the command will become. The implementation will be updated shortly to match the man page. A couple main differences from 'git checkout <paths>': - 'restore' by default will only update worktree. This matters more when --source is specified ('checkout <tree> <paths>' updates both worktree and index). - 'restore --staged' can be used to restore the index. This command overlaps with 'git reset <paths>'. - both worktree and index could also be restored at the same time (from a tree) when both --staged and --worktree are specified. This overlaps with 'git checkout <tree> <paths>' - default source for restoring worktree and index is the index and HEAD respectively. A different (tree) source could be specified as with --source (*). - when both index and worktree are restored, --source must be specified since the default source for these two individual targets are different (**) - --no-overlay is enabled by default, if an entry is missing in the source, restoring means deleting the entry (*) I originally went with --from instead of --source. I still think --from is a better name. The short option -f however is already taken by force. And I do think short option is good to have, e.g. to write -s@ or -s@^ instead of --source=HEAD. (**) If you sit down and think about it, moving worktree's source from the index to HEAD makes sense, but nobody is really thinking it through when they type the commands. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07git.txt: remove empty line before list continuationLibravatar Martin Ågren1-1/+0
This patch is a no-op for Asciidoctor, but makes AsciiDoc render this as intended. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-30Merge branch 'ah/doc-updates'Libravatar Junio C Hamano1-5/+5
Doc updates. * ah/doc-updates: doc: fix formatting in git-update-ref doc: fix indentation of listing blocks in gitweb.conf.txt doc: fix descripion for 'git tag --format' doc: fix inappropriate monospace formatting doc: fix ASCII art tab spacing doc: clarify boundaries of 'git worktree list --porcelain'
2018-10-23doc: fix inappropriate monospace formattingLibravatar Andreas Heiduk1-5/+5
Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-16Merge branch 'ma/mailing-list-address-in-git-help'Libravatar Junio C Hamano1-1/+3
Doc update. * ma/mailing-list-address-in-git-help: git doc: direct bug reporters to mailing list archive
2018-09-29git doc: direct bug reporters to mailing list archiveLibravatar Jonathan Nieder1-1/+3
The mailing list archive can help a user encountering a bug to tell whether a recent regression has already been reported and whether a longstanding bug has already had some discussion to start their thinking. Based-on-patch-by: Martin Ågren <martin.agren@gmail.com> Improved-by: Junio C Hamano <gitster@pobox.com> Improved-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-20Doc: use `--type=bool` instead of `--bool`Libravatar Martin Ågren1-1/+1
After fb0dc3bac1 (builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`, 2018-04-18) we have a more modern way of spelling `--bool`. Update all instances except those that explicitly document the "historical options" in git-config.txt. The other old-style type-specifiers already seem to be gone except for in that list of historical options. Tweak the grammar a little in config.txt while we are there. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-04Documentation/git.txt: clarify that GIT_TRACE=/path appendsLibravatar SZEDER Gábor1-2/+2
The current wording of the description of GIT_TRACE=/path/to/file ("... will try to write the trace messages into it") might be misunderstood as "overwriting"; at least I interpreted it that way on a cursory first read. State it more explicitly that the trace messages are appended. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-01Merge branch 'nd/command-list'Libravatar Junio C Hamano1-0/+10
The list of commands with their various attributes were spread across a few places in the build procedure, but it now is getting a bit more consolidated to allow more automation. * nd/command-list: completion: allow to customize the completable command list completion: add and use --list-cmds=alias completion: add and use --list-cmds=nohelpers Move declaration for alias.c to alias.h completion: reduce completable command list completion: let git provide the completable command list command-list.txt: documentation and guide line help: use command-list.txt for the source of guides help: add "-a --verbose" to list all commands with synopsis git: support --list-cmds=list-<category> completion: implement and use --list-cmds=main,others git --list-cmds: collect command list in a string_list git.c: convert --list-* to --list-cmds=* Remove common-cmds.h help: use command-list.h for common command list generate-cmds.sh: export all commands to command-list.h generate-cmds.sh: factor out synopsis extract code
2018-05-21completion: allow to customize the completable command listLibravatar Nguyễn Thái Ngọc Duy1-1/+2
By default we show porcelain, external commands and a couple others that are also popular. If you are not happy with this list, you can now customize it a new config variable. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21completion: add and use --list-cmds=aliasLibravatar Nguyễn Thái Ngọc Duy1-1/+1
By providing aliases via --list-cmds=, we could simplify command collection code in the script. We only issue one git command. Before this patch that is "git config", after it's "git --list-cmds=". In "git help" completion case we actually reduce one "git" process (for getting guides) but that call was added in this series so it does not really count. A couple of bash functions are removed because they are not needed anymore. __git_compute_all_commands() and $__git_all_commands stay because they are still needed for completing pager.* config and without "alias" group, the result is still cacheable. There is a slight (good) change in _git_help() with this patch: before "git help <tab>" shows external commands (as in _not_ part of git) as well as part of $__git_all_commands. We have finer control over command listing now and can exclude that because we can't provide a man page for external commands anyway. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21completion: add and use --list-cmds=nohelpersLibravatar Nguyễn Thái Ngọc Duy1-1/+2
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21git: support --list-cmds=list-<category>Libravatar Nguyễn Thái Ngọc Duy1-1/+2
This allows us to select any group of commands by a category defined in command-list.txt. This is an internal/hidden option so we don't have to be picky about the category name or worried about exposing too much. This will be used later by git-completion.bash to retrieve certain command groups. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21completion: implement and use --list-cmds=main,othersLibravatar Nguyễn Thái Ngọc Duy1-1/+2
This is part of the effort to break down and provide commands by category in machine-readable form. This could be helpful later on when completion script switches to use --list-cmds for selecting completable commands. It would be much easier for the user to choose to complete _all_ commands instead of the default selection by passing different values to --list-cmds in git-completino.bash. While at there, replace "git help -a" in git-completion.bash with --list-cmds since it's better suited for this task. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21git.c: convert --list-* to --list-cmds=*Libravatar Nguyễn Thái Ngọc Duy1-0/+6
Even if these are hidden options, let's make them a bit more generic since we're introducing more listing types shortly. The code is structured to allow combining multiple listing types together because we will soon add more types the 'builtins'. 'parseopt' remains separate because it has separate (SPC) to match git-completion.bash needs and will not combine with others. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04git: add -P as a short option for --no-pagerLibravatar Johannes Sixt1-1/+2
It is possible to configure 'less', the pager, to use an alternate screen to show the content, for example, by setting LESS=RS in the environment. When it is closed in this configuration, it switches back to the original screen, and all content is gone. It is not uncommon to request that the output remains visible in the terminal. For this, the option --no-pager can be used. But it is a bit cumbersome to type, even when command completion is available. Provide a short option, -P, to make the option more easily accessible. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-15Merge branch 'ab/man-sec-list'Libravatar Junio C Hamano1-0/+3
Doc update. * ab/man-sec-list: git manpage: note git-security@googlegroups.com