git/Documentation/git.txt, branch v2.31.2

git.txt: fix monospace rendering

2021-02-18T18:53:33Z

When we write ``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 Signed-off-by: Junio C Hamano

Merge branch 'ps/config-env-pairs'

2021-01-25T22:19:19Z

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`

2021-01-12T20:03:18Z

While it's already possible to pass runtime configuration via `git -c =`, 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==`. 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 Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

git.txt: fix typos in 'linkgit' macro invocation

2020-12-22T20:02:29Z

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 Signed-off-by: Junio C Hamano

refs: add GIT_TRACE_REFS debugging mechanism

2020-09-09T19:58:37Z

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 Signed-off-by: Junio C Hamano

Merge branch 'pb/doc-external-diff-env'

2020-09-03T19:37:09Z

Doc update. * pb/doc-external-diff-env: git.txt: correct stale 'GIT_EXTERNAL_DIFF' description

git.txt: correct stale 'GIT_EXTERNAL_DIFF' description

2020-09-01T19:17:05Z

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 Signed-off-by: Junio C Hamano

doc: mention GIT_SEQUENCE_EDITOR and 'sequence.editor' more

2020-08-31T18:45:05Z

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 Signed-off-by: Junio C Hamano

Merge branch 'ma/doc-sha-256-is-experimental'

2020-08-24T21:54:31Z

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 experimental

2020-08-17T17:50:14Z

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 Signed-off-by: Junio C Hamano