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

Sync with 2.39.4

2024-04-19T10:38:37Z

* maint-2.39: (38 commits) Git 2.39.4 fsck: warn about symlink pointing inside a gitdir core.hooksPath: add some protection while cloning init.templateDir: consider this config setting protected clone: prevent hooks from running during a clone Add a helper function to compare file contents init: refactor the template directory discovery into its own function find_hook(): refactor the `STRIP_EXTENSION` logic clone: when symbolic links collide with directories, keep the latter entry: report more colliding paths t5510: verify that D/F confusion cannot lead to an RCE submodule: require the submodule path to contain directories only clone_submodule: avoid using `access()` on directories submodules: submodule paths must not contain symlinks clone: prevent clashing git dirs when cloning submodule in parallel t7423: add tests for symlinked submodule directories has_dir_name(): do not get confused by characters < '/' docs: document security issues around untrusted .git dirs upload-pack: disable lazy-fetching by default fetch/clone: detect dubious ownership of local repositories ...

docs: document security issues around untrusted .git dirs

2024-04-17T20:29:57Z

For a long time our general philosophy has been that it's unsafe to run arbitrary Git commands if you don't trust the hooks or config in .git, but that running upload-pack should be OK. E.g., see 1456b043fc (Remove post-upload-hook, 2009-12-10), or the design of uploadpack.packObjectsHook. But we never really documented this (and even the discussions that led to 1456b043fc were not on the public list!). Let's try to make our approach more clear, but also be realistic that even upload-pack carries some risk. Helped-by: Filip Hejsek Helped-by: Junio C Hamano Signed-off-by: Jeff King Signed-off-by: Johannes Schindelin

Merge branch 'ar/markup-em-dash'

2023-01-30T22:24:24Z

Doc mark-up updates. * ar/markup-em-dash: Documentation: render dash correctly

Documentation: render dash correctly

2023-01-23T17:40:14Z

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

read-tree: add "--super-prefix" option, eliminate global

2022-12-26T01:21:44Z

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

Merge branch 'jc/environ-docs'

2022-10-10T17:08:41Z

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

Documentation: clean up a few misspelled word typos

2022-09-21T17:28:35Z

Used GNU "aspell check " to review various documentation files with the default aspell dictionary. Ignored false-positives between american and british english. Signed-off-by: Jacob Stopak Reviewed-by: Eric Sunshine Signed-off-by: Junio C Hamano

environ: GIT_INDEX_VERSION affects not just a new repository

2022-09-16T16:45:22Z

The variable is consulted whenever we write the index file. Signed-off-by: Junio C Hamano

environ: simplify description of GIT_INDEX_FILE

2022-09-16T16:45:21Z

Signed-off-by: Junio C Hamano

environ: GIT_FLUSH should be made a usual Boolean

2022-09-15T18:34:51Z

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