git/dir.c, branch v2.42.2

Sync with 2.41.1

2024-04-19T10:38:46Z

* maint-2.41: (38 commits) Git 2.41.1 Git 2.40.2 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 ...

Sync with 2.40.2

2024-04-19T10:38:42Z

* maint-2.40: (39 commits) Git 2.40.2 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 ...

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 ...

entry: report more colliding paths

2024-04-17T20:30:07Z

In b878579ae7 (clone: report duplicate entries on case-insensitive filesystems, 2018-08-17) code was added to warn about index entries that resolve to the same file system entity (usually the cause is a case-insensitive filesystem). In Git for Windows, where inodes are not trusted (because of a performance trade-off, inodes are equal to 0 by default), that check does not compare inode numbers but the verbatim path. This logic works well when index entries' paths differ only in case. However, for file/directory conflicts only the file's path was reported, leaving the user puzzled with what that path collides. Let's try ot catch colliding paths even if one path is the prefix of the other. We do this also in setups where the file system is case-sensitive because the inode check would not be able to catch those collisions. While not a complete solution (for example, on macOS, Unicode normalization could also lead to file/directory conflicts but be missed by this logic), it is at least another defensive layer on top of what the previous commits added. Signed-off-by: Johannes Schindelin

Merge branch 'jc/pathspec-match-with-common-prefix'

2023-07-17T18:30:43Z

"git ls-files '(attr:X)D/'" that triggers the common prefix optimization codepath failed to read from "D/.gitattributes", which has been corrected. * jc/pathspec-match-with-common-prefix: dir: match "attr" pathspec magic with correct paths t6135: attr magic with path pattern

dir: match "attr" pathspec magic with correct paths

2023-07-08T21:36:31Z

The match_pathspec_item() function takes "prefix" value, allowing a caller to chop off the common leading prefix of pathspec pattern strings from the path and only use the remainder of the path to match the pathspec patterns (after chopping the same leading prefix of them, of course). This "common leading prefix" optimization has two main features: * discard the entries in the in-core index that are outside of the common leading prefix; if you are doing "ls-files one/a one/b", we know all matches must be from "one/", so first the code discards all entries outside the "one/" directory from the in-core index. This allows us to work on a smaller dataset. * allow skipping the comparison of the leading bytes when matching pathspec with path. When "ls-files" finds the path "one/a/1" in the in-core index given "one/a" and "one/b" as the pathspec, knowing that common leading prefix "one/" was found lets the pathspec matchinery not to bother comparing "one/" part, and allows it to feed "a/1" down, as long as the pathspec element "one/a" gets corresponding adjustment to "a". When the "attr" pathspec magic is in effect, however, the current code breaks down. The attributes, other than the ones that are built-in and the ones that come from the $GIT_DIR/info/attributes file and the top-level .gitattributes file, are lazily read from the filesystem on-demand, as we encounter each path and ask if it matches the pathspec. For example, if you say "git ls-files "(attr:label)sub/" in a repository with a file "sub/file" that is given the 'label' attribute in "sub/.gitattributes": * The common prefix optimization finds that "sub/" is the common prefix and prunes the in-core index so that it has only entries inside that directory. This is desirable. * The code then walks the in-core index, finds "sub/file", and eventually asks do_match_pathspec() if it matches the given pathspec. * do_match_pathspec() calls match_pathspec_item() _after_ stripping the common prefix "sub/" from the path, giving it "file", plus the length of the common prefix (4-bytes), so that the pathspec element "(attr:label)sub/" can be treated as if it were "(attr:label)". The last one is what breaks the match in the current code, as the pathspec subsystem ends up asking the attribute subsystem to find the attribute attached to the path "file". We need to ask about the attributes on "sub/file" when calling match_pathspec_attrs(); this can be done by looking at "prefix" bytes before the beginning of "name", which is the same trick already used by another piece of the code in the same match_pathspec_item() function. Unfortunately this was not discovered so far because the code works with slightly different arguments, e.g. $ git ls-files "(attr:label)sub" $ git ls-files "(attr:label)sub/" "no/such/dir/" would have reported "sub/file" as a path with the 'label' attribute just fine, because neither would trigger the common prefix optimization. Reported-by: Matthew Hughes Signed-off-by: Junio C Hamano

git-compat-util: move alloc macros to git-compat-util.h

2023-07-05T18:42:31Z

alloc_nr, ALLOC_GROW, and ALLOC_GROW_BY are commonly used macros for dynamic array allocation. Moving these macros to git-compat-util.h with the other alloc macros focuses alloc.[ch] to allocation for Git objects and additionally allows us to remove inclusions to alloc.h from files that solely used the above macros. Signed-off-by: Calvin Wan Signed-off-by: Junio C Hamano

treewide: remove unnecessary includes for wrapper.h

2023-07-05T18:41:59Z

Signed-off-by: Calvin Wan Signed-off-by: Junio C Hamano

fsmonitor-ll.h: split this header out of fsmonitor.h

2023-06-21T20:39:54Z

This creates a new fsmonitor-ll.h with most of the functions from fsmonitor.h, though it leaves three inline functions where they were. Two-thirds of the files that previously included fsmonitor.h did not need those three inline functions or the six extra includes those inline functions required, so this allows them to only include the lower level header. Diff best viewed with `--color-moved`. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

object-store-ll.h: split this header out of object-store.h

2023-06-21T20:39:54Z

The vast majority of files including object-store.h did not need dir.h nor khash.h. Split the header into two files, and let most just depend upon object-store-ll.h, while letting the two callers that need it depend on the full object-store.h. After this patch: $ git grep -h include..object-store | sort | uniq -c 2 #include "object-store.h" 129 #include "object-store-ll.h" Diff best viewed with `--color-moved`. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano