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

Merge branch 'ma/doc-git-version'

2021-10-29T22:43:14Z

Typofix. * ma/doc-git-version: git.txt: fix typo

git.txt: fix typo

2021-10-25T17:19:30Z

Fix the spelling of "internally". Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

refs: turn on GIT_REF_PARANOIA by default

2021-09-27T19:36:45Z

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

Merge branch 'ma/doc-git-version'

2021-09-23T20:44:49Z

Doc update. * ma/doc-git-version: documentation: add documentation for 'git version'

documentation: add documentation for 'git version'

2021-09-14T17:05:40Z

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

docs/git: discuss server-side config for GIT_PROTOCOL

2021-09-10T22:34:59Z

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

Merge branch 'ps/config-global-override'

2021-05-07T03:47:39Z

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()`

Merge branch 'ps/config-env-option-with-separate-value'

2021-05-07T03:47:37Z

"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 sign

2021-04-30T00:46:46Z

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 Signed-of-by: Patrick Steinhardt Reviewed-by: Jeff King Signed-off-by: Junio C Hamano

config: allow overriding of global and system configuration

2021-04-19T21:16:59Z

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