Skip to content
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.

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

wildmatch: re-introduce WM_PATHNAME #7

Closed
wants to merge 1 commit into from
Closed

Conversation

ttaylorr
Copy link
Contributor

@ttaylorr ttaylorr commented Jul 5, 2018

This pull request re-introduces the WM_PATHNAME option from Git's wildmatch.c, which treats '*' as able to match across directory boundaries, as if all * were re-written as **/*'s.

This option is already somewhat used in Git LFS, when translating from filepathfilter-style path matches to .gitattributes style matches in:

https://github.com/git-lfs/git-lfs/blob/5e601f8aa040e7e8c998c2c853dda844fa156789/filepathfilter/filepathfilter.go#L102

While implementing a .gitattributes parser over the gitobj package, I found it useful to have this option to translate patterns like *.dat into patterns like **/*.dat such that they could be used to match children at arbitrary depth.

/cc @git-lfs/core

Copy link

@PastelMobileSuit PastelMobileSuit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, I'm really glad we're adding this to wildmatch! I just had a few small comments/questions

// pathname converts patterns of the form "foo*.txt" to "foo/**/*.txt", thus
// in-effect allowing the "*" operator to match multiple directory levels at
// once.
func pathname(p string) string {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this function can be a bit tough to follow, so it might be worth adding a few comments

func TestPathname(t *testing.T) {
for _, c := range []*PathnameCase{
{Given: "*.txt", Expect: "**/*.txt"},
{Given: "foo*.txt", Expect: "foo/**/*.txt"},

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MIght also be worth having a case like

{Given: "foo/*/*.txt", Expect: "foo/**/*/**/*.txt"}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would also be worth having a case involving a ** in the path somewhere to make sure that's properly preserved. Also, should a **/* pattern expand to **/**/*? If so, that might also be worth adding a test case for.

@@ -69,6 +83,32 @@ const (
escapes = "\\[]*?"
)

// pathname converts patterns of the form "foo*.txt" to "foo/**/*.txt", thus

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should foo*.txt be converted? I couldn't find any documentation on Git's Wildmatch code, but I know with a unix file glob foo*.txt would match foo.txt, fooabc.txt, etc., but not foo/abc.txt.

@ttaylorr
Copy link
Contributor Author

ttaylorr commented Jul 6, 2018

@PastelMobileSuit Thanks for the review, I appreciate you pouring through func pathname; it could certainly use a few guiding comments.

Your questions, in particular #7 (comment) made me think about whether or not this is the right approach. I can't recall seeing specific rules about when it is and is not OK to transition * to **/* anywhere in Git. For instance, I haven't seen a rule that says, "it's OK when it's between directory separators" or, "it's not OK when it's interspersed between a word."

So, I consulted Git's attr.c where much of this behavior is defined, and realized that this approach is completely off. Instead, I wrote #8, which mirrors what I now hold to be the correct behavior.

If you wouldn't mind dropping another review on that instead, I think we should close this out and move discussion there.

@ttaylorr ttaylorr closed this Jul 6, 2018
@ttaylorr ttaylorr deleted the wm-pathname branch July 6, 2018 02:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants