summaryrefslogtreecommitdiff
path: root/Documentation/git.txt
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'jc/attr-source-tree'Junio C Hamano2023-05-171-0/+8
|\ | | | | | | | | | | | | | | | | "git --attr-source=<tree> cmd $args" is a new way to have any command to read attributes not from the working tree but from the given tree object. * jc/attr-source-tree: attr: teach "--attr-source=<tree>" global option to "git"
| * attr: teach "--attr-source=<tree>" global option to "git"John Cai2023-05-061-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Earlier, 47cfc9bd (attr: add flag `--source` to work with tree-ish, 2023-01-14) taught "git check-attr" the "--source=<tree>" option to allow it to read attribute files from a tree-ish, but did so only for the command. Just like "check-attr" users wanted a way to use attributes from a tree-ish and not from the working tree files, users of other commands (like "git diff") would benefit from the same. Undo most of the UI change the commit made, while keeping the internal logic to read attributes from a given tree-ish. Expose the internal logic via a new "--attr-source=<tree>" command line option given to "git", so that it can be used with any git command that runs as part of the main git process. Additionally, add an environment variable GIT_ATTR_SOURCE that is set when --attr-source is passed in, so that subprocesses use the same value for the attributes source tree. Signed-off-by: John Cai <johncai86@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jc/doc-clarify-git-default-hash-variable'Junio C Hamano2023-05-151-3/+3
|\ \ | |/ |/| | | | | | | | | | | | | The documentation was misleading about the interaction between GIT_DEFAULT_HASH and "git clone", which has been clarified to stress that the variable is to be ignored by the command. * jc/doc-clarify-git-default-hash-variable: doc: GIT_DEFAULT_HASH is and will be ignored during "clone"
| * doc: GIT_DEFAULT_HASH is and will be ignored during "clone"Junio C Hamano2023-04-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The phrasing "is currently ignored" was prone to be misinterpreted as if we were wishing if it were honored. Rephrase it to make it clear that the experimental variable will be ignored. In the longer term, after/when we allow incremental/over-the-wire migration of the object-format, i.e. cloning from an SHA-1 repository to create an SHA-256 repository (or vice versa) and fetching and pushing between them would bidirectionally convert the object format on the fly, it is likely that we would teach a new option "--object-format" to "git clone" to say "you would use whatever object format the origin uses by default, but this time, I am telling you to use this format on our side, doing on-the-fly object format conversion as needed". So it is perfectly OK to ignore the settings of this experimental variable, even after such an extension happens that makes it necessary for us to have a way to create a new repository that uses different object format from the origin repository. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Merge branch 'jc/environ-docs' into maint-2.38Junio C Hamano2022-10-271-16/+27
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Documentation on various Boolean GIT_* environment variables have been clarified. * jc/environ-docs: environ: GIT_INDEX_VERSION affects not just a new repository environ: simplify description of GIT_INDEX_FILE environ: GIT_FLUSH should be made a usual Boolean environ: explain Boolean environment variables environ: document GIT_SSL_NO_VERIFY
* | \ Merge branch 'ar/markup-em-dash'Junio C Hamano2023-01-301-1/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Doc mark-up updates. * ar/markup-em-dash: Documentation: render dash correctly
| * | | Documentation: render dash correctlyAndrei Rybak2023-01-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Three hyphens are rendered verbatim in documentation, so "--" has to be used to produce a dash. Fix asciidoc output for dashes. This is similar to previous commits f0b922473e (Documentation: render special characters correctly, 2021-07-29) and de82095a95 (doc hash-function-transition: fix asciidoc output, 2021-02-05). Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | read-tree: add "--super-prefix" option, eliminate globalÆvar Arnfjörð Bjarmason2022-12-261-7/+1
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "--super-prefix" option to "git" was initially added in [1] for use with "ls-files"[2], and shortly thereafter "submodule--helper"[3] and "grep"[4]. It wasn't until [5] that "read-tree" made use of it. At the time [5] made sense, but since then we've made "ls-files" recurse in-process in [6], "grep" in [7], and finally "submodule--helper" in the preceding commits. Let's also remove it from "read-tree", which allows us to remove the option to "git" itself. We can do this because the only remaining user of it is the submodule API, which will now invoke "read-tree" with its new "--super-prefix" option. It will only do so when the "submodule_move_head()" function is called. That "submodule_move_head()" function was then only invoked by "read-tree" itself, but now rather than setting an environment variable to pass "--super-prefix" between cmd_read_tree() we: - Set a new "super_prefix" in "struct unpack_trees_options". The "super_prefixed()" function in "unpack-trees.c" added in [5] will now use this, rather than get_super_prefix() looking up the environment variable we set earlier in the same process. - Add the same field to the "struct checkout", which is only needed to ferry the "super_prefix" in the "struct unpack_trees_options" all the way down to the "entry.c" callers of "submodule_move_head()". Those calls which used the super prefix all originated in "cmd_read_tree()". The only other caller is the "unlink_entry()" caller in "builtin/checkout.c", which now passes a "NULL". 1. 74866d75793 (git: make super-prefix option, 2016-10-07) 2. e77aa336f11 (ls-files: optionally recurse into submodules, 2016-10-07) 3. 89c86265576 (submodule helper: support super prefix, 2016-12-08) 4. 0281e487fd9 (grep: optionally recurse into submodules, 2016-12-16) 5. 3d415425c7b (unpack-trees: support super-prefix option, 2017-01-17) 6. 188dce131fa (ls-files: use repository object, 2017-06-22) 7. f9ee2fcdfa0 (grep: recurse in-process using 'struct repository', 2017-08-02) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jc/environ-docs'Junio C Hamano2022-10-101-16/+27
|\ \ \ | |/ / |/| / | |/ | | | | | | | | | | | | | | | | Documentation on various Boolean GIT_* environment variables have been clarified. * jc/environ-docs: environ: GIT_INDEX_VERSION affects not just a new repository environ: simplify description of GIT_INDEX_FILE environ: GIT_FLUSH should be made a usual Boolean environ: explain Boolean environment variables environ: document GIT_SSL_NO_VERIFY
| * environ: GIT_INDEX_VERSION affects not just a new repositoryJunio C Hamano2022-09-161-2/+2
| | | | | | | | | | | | The variable is consulted whenever we write the index file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * environ: simplify description of GIT_INDEX_FILEJunio C Hamano2022-09-161-1/+1
| | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * environ: GIT_FLUSH should be made a usual BooleanJunio C Hamano2022-09-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | This uses atoi() and checks if the result is not zero to decide what to do. Turning it into the usual Boolean environment variable to use git_env_bool() would not break those who have been using "set to 0, or set to non-zero, that can be parsed with atoi()" values, but will match the expectation of those who expected "true" to mean "yes". Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * environ: explain Boolean environment variablesJunio C Hamano2022-09-151-13/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | Many environment variables use the git_env_bool() API to parse their values, and allow the usual "true/yes/on are true, false/no/off are false. In addition non-zero numbers are true and zero is false. An empty string is also false." set of values. Mark them as such, and consistently say "true" or "false", instead of random mixes of '1', '0', 'yes', 'true', etc. in their description. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * environ: document GIT_SSL_NO_VERIFYJunio C Hamano2022-09-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Even though the name of the environment variable is mentioned in "git config --help" from http.sslVerify, there is no description for it. Add one. Note that this is not a usual Boolean environment variable whose value can be yes/true/on vs no/false/off; the existence of it is enough to trigger the feature named by the variable. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Documentation: clean up a few misspelled word typosJacob Stopak2022-09-211-1/+1
| | | | | | | | | | | | | | | | | | | | Used GNU "aspell check <filename>" to review various documentation files with the default aspell dictionary. Ignored false-positives between american and british english. Signed-off-by: Jacob Stopak <jacob@initialcommit.io> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ab/tech-docs-to-help'Junio C Hamano2022-08-141-0/+17
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Expose a lot of "tech docs" via "git help" interface. * ab/tech-docs-to-help: docs: move http-protocol docs to man section 5 docs: move cruft pack docs to gitformat-pack docs: move pack format docs to man section 5 docs: move signature docs to man section 5 docs: move index format docs to man section 5 docs: move protocol-related docs to man section 5 docs: move commit-graph format docs to man section 5 git docs: add a category for file formats, protocols and interfaces git docs: add a category for user-facing file, repo and command UX git help doc: use "<doc>" instead of "<guide>" help.c: remove common category behavior from drop_prefix() behavior help.c: refactor drop_prefix() to use a "switch" statement"
| * git docs: add a category for file formats, protocols and interfacesÆvar Arnfjörð Bjarmason2022-08-041-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a new "File formats, protocols and other developer interfaces" section in the main "git help git" manual page and start moving the documentation that now lives in "Documentation/technical/*.git" over to it. This complements the newly added and adjacent "Repository, command and file interfaces" section. This makes the technical documentation more accessible and discoverable. Before this we wouldn't install it by default, and had no ability to build man page versions of them. The links to them from our existing documentation link to the generated HTML version of these docs. So let's start moving those over, starting with just the "bundle-format.txt" documentation added in 7378ec90e1c (doc: describe Git bundle format, 2020-02-07). We'll now have a new gitformat-bundle(5) man page. Subsequent commits will move more git internal format documentation over. Unfortunately the syntax of the current Documentation/technical/*.txt is not the same (when it comes to section headings etc.) as our Documentation/*.txt documentation, so change the relevant bits of syntax as we're moving this over. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git docs: add a category for user-facing file, repo and command UXÆvar Arnfjörð Bjarmason2022-08-041-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a new "Repository, command and file interfaces" section in the main "git help git" manual page. Move things that belong under this new criteria from the generic "Guides" section. The "Guides" section was added in f442f28a81b (git.txt: add list of guides, 2020-08-05). It makes sense to have e.g. "giteveryday(7)" and "gitfaq(7)" listed under "Guides". But placing e.g. "gitignore(5)" in it is stretching the meaning of what a "guide" is, ideally that section should list things similar to "giteveryday(7)" and "gitcore-tutorial(7)". An alternate name that was considered for this new section was "User formats", for consistency with the nomenclature used for man section 5 in general. My man(1) lists it as "File formats and conventions, e.g. /etc/passwd". So calling this "git help --formats" or "git help --user-formats" would make sense for e.g. gitignore(5), but would be stretching it somewhat for githooks(5), and would seem really suspect for the likes of gitcli(7). Let's instead pick a name that's closer to the generic term "User interface", which is really what this documentation discusses: General user-interface documentation that doesn't obviously belong elsewhere. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git.txt: remove redundant languageDerrick Stolee2022-07-191-3/+1
|/ | | | | | | | | | | | | The documentation for GIT_ALLOW_PROTOCOL has a sentence that adds no value, since it repeats the meaning from the previous sentence (twice!). The word "whitelist" has cultural implications that are not inclusive, which brought attention to this sentence. Helped-by: Jeff King <peff@peff.net> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cli: add -v and -h shorthandsGarrit Franke2022-03-311-1/+3
| | | | | | | | | | | | | | | | | | Change the behavior of "git -v" to be synonymous with "--version" / "version", and "git -h" to be synonymous with "--help", but not "help". These shorthands both display the "unknown option" message. Following this change, "-v" displays the version, and "-h" displays the help text of the "git" command. It should be noted that the "-v" shorthand could be misinterpreted by the user to mean "verbose" instead of "version", since some sub-commands make use of it in this context. The top-level "git" command does not have a "verbose" flag, so it's safe to introduce this shorthand unambiguously. Signed-off-by: Garrit Franke <garrit@slashdev.space> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'if/redact-packfile-uri'Junio C Hamano2021-12-101-2/+3
|\ | | | | | | | | | | | | | | Redact the path part of packfile URI that appears in the trace output. * if/redact-packfile-uri: http-fetch: redact url on die() message fetch-pack: redact packfile urls in traces
| * fetch-pack: redact packfile urls in tracesIvan Frade2021-11-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | In some setups, packfile uris act as bearer token. It is not recommended to expose them plainly in logs, although in special circunstances (e.g. debug) it makes sense to write them. Redact the packfile URL paths by default, unless the GIT_TRACE_REDACT variable is set to false. This mimics the redacting of the Authorization header in HTTP. Signed-off-by: Ivan Frade <ifrade@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ma/doc-git-version'Junio C Hamano2021-10-291-1/+1
|\ \ | |/ |/| | | | | | | | | Typofix. * ma/doc-git-version: git.txt: fix typo
| * git.txt: fix typoMartin Ågren2021-10-251-1/+1
| | | | | | | | | | | | | | Fix the spelling of "internally". Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | refs: turn on GIT_REF_PARANOIA by defaultJeff King2021-09-271-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original point of the GIT_REF_PARANOIA flag was to include broken refs in iterations, so that possibly-destructive operations would not silently ignore them (and would generally instead try to operate on the oids and fail when the objects could not be accessed). We already turned this on by default for some dangerous operations, like "repack -ad" (where missing a reachability tip would mean dropping the associated history). But it was not on for general use, even though it could easily result in the spreading of corruption (e.g., imagine cloning a repository which simply omits some of its refs because their objects are missing; the result quietly succeeds even though you did not clone everything!). This patch turns on GIT_REF_PARANOIA by default. So a clone as mentioned above would actually fail (upload-pack tells us about the broken ref, and when we ask for the objects, pack-objects fails to deliver them). This may be inconvenient when working with a corrupted repository, but: - we are better off to err on the side of complaining about corruption, and then provide mechanisms for explicitly loosening safety. - this is only one type of corruption anyway. If we are missing any other objects in the history that _aren't_ ref tips, then we'd behave similarly (happily show the ref, but then barf when we started traversing). We retain the GIT_REF_PARANOIA variable, but simply default it to "1" instead of "0". That gives the user an escape hatch for loosening this when working with a corrupt repository. It won't work across a remote connection to upload-pack (because we can't necessarily set environment variables on the remote), but there the client has other options (e.g., choosing which refs to fetch). As a bonus, this also makes ref iteration faster in general (because we don't have to call has_object_file() for each ref), though probably not noticeably so in the general case. In a repo with a million refs, it shaved a few hundred milliseconds off of upload-pack's advertisement; that's noticeable, but most repos are not nearly that large. The possible downside here is that any operation which iterates refs but doesn't ever open their objects may now quietly claim to have X when the object is corrupted (e.g., "git rev-list new-branch --not --all" will treat a broken ref as uninteresting). But again, that's not really any different than corruption below the ref level. We might have refs/heads/old-branch as non-corrupt, but we are not actively checking that we have the entire reachable history. Or the pointed-to object could even be corrupted on-disk (but our "do we have it" check would still succeed). In that sense, this is merely bringing ref-corruption in line with general object corruption. One alternative implementation would be to actually check for broken refs, and then _immediately die_ if we see any. That would cause the "rev-list --not --all" case above to abort immediately. But in many ways that's the worst of all worlds: - it still spends time looking up the objects an extra time - it still doesn't catch corruption below the ref level - it's even more inconvenient; with the current implementation of GIT_REF_PARANOIA for something like upload-pack, we can make the advertisement and let the client choose a non-broken piece of history. If we bail as soon as we see a broken ref, they cannot even see the advertisement. The test changes here show some of the fallout. A non-destructive "git repack -adk" now fails by default (but we can override it). Deleting a broken ref now actually tells the hooks the correct "before" state, rather than a confusing null oid. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ma/doc-git-version'Junio C Hamano2021-09-231-0/+4
|\ \ | |/ | | | | | | | | | | Doc update. * ma/doc-git-version: documentation: add documentation for 'git version'
| * documentation: add documentation for 'git version'Matthias Aßhauer2021-09-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While 'git version' is probably the least complex git command, it is a non-experimental user-facing builtin command. As such it should have a help page. Both `git help` and `git version` can be called as options (`--help`/`--version`) that internally get converted to the corresponding command. Add a small paragraph to Documentation/git.txt describing how these two options interact with each other and link to this help page for the sub-options that `--version` can take. Well, currently there is only one sub-option, but that could potentially increase in future versions of Git. Signed-off-by: Matthias Aßhauer <mha1993@live.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | docs/git: discuss server-side config for GIT_PROTOCOLJeff King2021-09-101-0/+15
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | The v2 protocol requires that the GIT_PROTOCOL environment variable gets passed around, but we don't have any documentation describing how this is supposed to work. In particular, we need to note what server admins might need to configure to make things work. The definition of the GIT_PROTOCOL variable is probably the best place for this, since: - we deal with multiple transports (ssh, http, etc). Transport-specific documentation (like the git-http-backend bits added in the previous commit) are helpful for those transports, but this gives a broader overview. Plus we do not have a specific transport endpoint program for ssh, so this is a reasonable place to mention it. - the server side of the protocol involves multiple programs. For now, upload-pack is the only endpoint which uses GIT_PROTOCOL, but that will likely expand in the future. We're better off with a central discussion of what the server admin might need to do. However, for discoverability, this patch adds a pointer from upload-pack's documentation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ps/config-global-override'Junio C Hamano2021-05-071-0/+10
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace GIT_CONFIG_NOSYSTEM mechanism to decline from reading the system-wide configuration file with GIT_CONFIG_SYSTEM that lets users specify from which file to read the system-wide configuration (setting it to an empty file would essentially be the same as setting NOSYSTEM), and introduce GIT_CONFIG_GLOBAL to override the per-user configuration in $HOME/.gitconfig. * ps/config-global-override: t1300: fix unset of GIT_CONFIG_NOSYSTEM leaking into subsequent tests config: allow overriding of global and system configuration config: unify code paths to get global config paths config: rename `git_etc_config()`
| * config: allow overriding of global and system configurationPatrick Steinhardt2021-04-191-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to have git run in a fully controlled environment without any misconfiguration, it may be desirable for users or scripts to override global- and system-level configuration files. We already have a way of doing this, which is to unset both HOME and XDG_CONFIG_HOME environment variables and to set `GIT_CONFIG_NOGLOBAL=true`. This is quite kludgy, and unsetting the first two variables likely has an impact on other executables spawned by such a script. The obvious way to fix this would be to introduce `GIT_CONFIG_NOGLOBAL` as an equivalent to `GIT_CONFIG_NOSYSTEM`. But in the past, it has turned out that this design is inflexible: we cannot test system-level parsing of the git configuration in our test harness because there is no way to change its location, so all tests run with `GIT_CONFIG_NOSYSTEM` set. Instead of doing the same mistake with `GIT_CONFIG_NOGLOBAL`, introduce two new variables `GIT_CONFIG_GLOBAL` and `GIT_CONFIG_SYSTEM`: - If unset, git continues to use the usual locations. - If set to a specific path, we skip reading the normal configuration files and instead take the path. By setting the path to `/dev/null`, no configuration will be loaded for the respective level. This implements the usecase where we want to execute code in a sanitized environment without any potential misconfigurations via `/dev/null`, but is more flexible and allows for more usecases than simply adding `GIT_CONFIG_NOGLOBAL`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ps/config-env-option-with-separate-value'Junio C Hamano2021-05-071-1/+1
|\ \ | |/ |/| | | | | | | | | | | | | "git --config-env var=val cmd" weren't accepted (only --config-env=var=val was). * ps/config-env-option-with-separate-value: git: support separate arg for `--config-env`'s value git.txt: fix synopsis of `--config-env` missing the equals sign
| * git.txt: fix synopsis of `--config-env` missing the equals signPatrick Steinhardt2021-04-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When executing `git -h`, then the `--config-env` documentation rightly lists the option as requiring an equals between the option and its argument: this is the only currently supported format. But the git(1) manpage incorrectly lists the option as taking a space in between. Fix the issue by adding the missing space. Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-of-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git.txt: fix monospace renderingMartin Ågren2021-02-181-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>
* | Merge branch 'ps/config-env-pairs'Junio C Hamano2021-01-251-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
| * config: add new way to pass config via `--config-env`Patrick Steinhardt2021-01-121-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>
* | git.txt: fix typos in 'linkgit' macro invocationPhilippe Blain2020-12-221-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>
* refs: add GIT_TRACE_REFS debugging mechanismHan-Wen Nienhuys2020-09-091-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>
* Merge branch 'pb/doc-external-diff-env'Junio C Hamano2020-09-031-2/+3
|\ | | | | | | | | | | | | Doc update. * pb/doc-external-diff-env: git.txt: correct stale 'GIT_EXTERNAL_DIFF' description
| * git.txt: correct stale 'GIT_EXTERNAL_DIFF' descriptionPhilippe Blain2020-09-011-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>
* | doc: mention GIT_SEQUENCE_EDITOR and 'sequence.editor' morePhilippe Blain2020-08-311-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>
* | Merge branch 'ma/doc-sha-256-is-experimental'Junio C Hamano2020-08-241-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
| * | Documentation: mark `--object-format=sha256` as experimentalMartin Ågren2020-08-171-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>
* | git.txt: add list of guidesPhilippe Blain2020-08-041-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>
* Merge branch 'jt/redact-all-cookies'Junio C Hamano2020-06-221-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
| * http: redact all cookies, teach GIT_TRACE_REDACT=0Jonathan Tan2020-06-051-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>
* | Merge branch 'jt/curl-verbose-on-trace-curl'Junio C Hamano2020-06-081-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
| * http, imap-send: stop using CURLOPT_VERBOSEJonathan Tan2020-05-111-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>
* | Documentation: correct hash environment variableToon Claes2020-05-271-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>
* builtin/init-db: add environment variable for new repo hashbrian m. carlson2020-02-241-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>
* Merge branch 'hw/doc-git-dir'Junio C Hamano2020-02-121-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
View Lorry Controller Status