8000 `git_pathspec_matches_path` not working with leading `**/` on pattern · Issue #6946 · libgit2/libgit2 · GitHub
[go: up one dir, main page]
Skip to content

git_pathspec_matches_path not working with leading **/ on pattern #6946

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
8000
kip93 opened this issue Nov 25, 2024 · 5 comments
Open

git_pathspec_matches_path not working with leading **/ on pattern #6946

kip93 opened this issue Nov 25, 2024 · 5 comments

Comments

@kip93
Copy link
kip93 commented Nov 25, 2024

Reproduction steps

--- a/tests/libgit2/repo/pathspec.c
+++ b/tests/libgit2/repo/pathspec.c
@@ -383,3 +383,16 @@ void test_repo_pathspec__in_memory(void)
 
        git_pathspec_free(ps);
 }
+
+void test_repo_pathspec__foo(void)
+{
+       static char *strings[] = { "**/foo" };
+       git_strarray s = { strings, ARRAY_SIZE(strings) };
+       git_pathspec *ps;
+
+       cl_git_pass(git_pathspec_new(&ps, &s));
+
+       cl_assert(git_pathspec_matches_path(ps, 0, "foo"));
+
+       git_pathspec_free(ps);
+}

Expected behavior

According to the git documentation:

A leading "**" followed by a slash means match in all directories. For example, "**/foo" matches file or directory "foo" anywhere, the same as pattern "foo". "**/foo/bar" matches file or directory "bar" anywhere that is directly under directory "foo".

Actual behavior

git_pathspec_matches_path returns no matches

$ ./libgit2_tests -srepo::pathspec
Loaded 384 suites: 
Started (test status codes: OK='.' FAILURE='F' SKIPPED='S')
..........F

  1) Failure:
repo::pathspec::foo [/home/kip/Documents/libgit2/tests/libgit2/repo/pathspec.c:395]
  Expression is not true: git_pathspec_matches_path(ps, 0, "foo")

Version of libgit2 (release number or SHA1)

Both 1.7.2 and latest main (0a6051c624fc3403e89a6a6679526126e587a401)

Operating system(s) tested

Linux (NixOS 24.05)
kip93 added a commit to kip93/nix that referenced this issue Nov 25, 2024
@kip93
Work around libgit2/libgit2#6946
c9a8bd6
@ethomson
Copy link
Member

I believe that it does. The documentation you're referencing is vague, or perhaps simply wrong, compared to how git actually works. git status takes a pathspec. **/foo doesn't actually match a top-level foo, only foo in any subdirectory. Consider:

git init .
morbo:/tmp/foo% git init .
Initialized empty Git repository in /private/tmp/foo/.git/
morbo:/tmp/foo% touch foo
morbo:/tmp/foo% mkdir subdir && touch subdir/foo
morbo:/tmp/foo% mkdir -p a/b/c/d && touch a/b/c/d/foo
morbo:/tmp/foo% git status '**/foo'
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	a/b/c/d/foo
	subdir/foo

nothing added to commit but untracked files present (use "git add" to track)

@ethomson
Copy link
Member

See #6959

@kip93
Copy link
Author
kip93 commented Dec 11, 2024

Interesting, maybe I'm confusing a path spec with a path pattern? I came about this since I found issues when processing some git attributes, but maybe those use a different logic then? (or is a bug in upstream git?) I can confirm that when the same is used on a .gitignore or a .gitattributes it indeed works as I described.

@ethomson
Copy link
Member

Ah, indeed, there are some differences because of course there are. (For example, within the list of patterns in a gitignore or attributes file, you can negate patterns.)

I don't think that we have a particularly self-contained mechanism like git_pathspec_matches_path - where you it takes a list of patterns (IOW, the contents of a gitignore file) and a path and get back a "is matched" boolean. Is that what you're looking for?

@kip93
Copy link
Author
kip93 commented Dec 11, 2024

Yes, I think that's what I thought this function did too, but apparently I was mistaken. Should I close this and open a feature request to track this use case?

@ethomson ethomson mentioned this issue Dec 13, 2024
Merged
@kip93 kip93 mentioned this issue Dec 16, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ethomson @kip93
0