Giter VIP home page Giter VIP logo

ignore's People

Contributors

goelhardik avatar hagoelms avatar jairbubbles avatar jkamsker avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

ignore's Issues

Bug Ignore.Add("folder") match also folder with prefix

Hello, I have problem with this case:

Unit test:

[TestCase]
    public void TestIngoreMorePatterns()
    {
        var ignore = new Ignore.Ignore();
        ignore.Add("!.gitignore");
        ignore.Add("folder");

        ignore.IsIgnored(@".gitignore").Should().BeFalse();
        ignore.IsIgnored(@"src/Testfolder/.gitignore").Should().BeFalse();
        ignore.IsIgnored(@"tools/Testfolder/.gitignore").Should().BeFalse();
}

Test is failing but it should not. Testfolder is not folder.

Windows path separators are not accepted interchangeably

Windows allows either / or \ for path chars, however if a rule is ".vs/*" but the path passed in is ".vs\myfile.txt" it does not say it should be ignored. Replacing all backslashes with forward slashes in both the initial path adding and match tries should fix it but would be good if it worked like git.

Support ReadOnlySpan<char> for IsMatch()

Example:

  public bool IsMatch(ReadOnlySpan<char> input)
    {
        return parsedRegex != null && parsedRegex.IsMatch(input);
    }

Just add that signature in addition to the one taking string.

This reduces my time of scanning 200K files from 1.79 --> 1.57 seconds.

It's because the ReadOnlySpan supports an efficient Slice() operation, so I'm not scanning the part of the path above where the .gitignore file resides.

I'm the author of ViLark, a file chooser for vim, sort of like fzf.

And thanks for this library, it helps a lot. Although I am getting very slow performance with a wildcard like '*.pyc', I might dig into that if I have time.

Absolute path not property handled

        [Fact]
        public void SimpleIgnore_Dotfiles_WithStar2() => GitBasedTest(
            @"""
.vs/*
""",
            new[] { "C:/foo/.vs/a.txt", "foo/.vs/a.txt", ".vs/a.txt" });

C:/foo/.vs/a.txt should be ignored by the lib and is not.

I'm not sure why "foo/.vs/a.txt" is not ignored though ๐Ÿ˜”

Dotfiles are not handled correctly

var ignore = new Ignore.Ignore();
ignore.Add(".*");

ignore.IsIgnored("/.dotfile").Dump(); // returns true
ignore.IsIgnored("/no.dotfile").Dump(); // returns true

The second one should not be ignored.

Tested using git.
Gitignore:

.*

Created the files .dotfile and no.dotfile: no.dotfile shows up in the changes tab.

StarPlus not properly handled

*+ => .*+(/.*)?$ will generate an error:

System.Text.RegularExpressions.RegexParseException
Invalid pattern '.*+(/.*)?$' at offset 3. Nested quantifier '+'.

(taken from git's .gitignore)

Issue with pattern containing multiple dots

Didn't have time to investigate more but this test is failing:

        [Fact]
        public void SimpleIgnore_Dotfiles_WithStar3() => GitBasedTest(
            @"""
*.mm.*
""",
            new[] { "file.mm", "commonFile.txt" });

"commonFile.txt" is ignored by the lib.

Problem with Visual Studio .gitignore and folder names

There is a problem with some of the Visual Studio .gitignore rules.

https://github.com/github/gitignore/blob/main/VisualStudio.gitignore

The problem is these folder rules:

[Dd]ebug/
[Dd]ebugPublic/
[Rr]elease/
[Rr]eleases/
x64/
x86/
[Ww][Ii][Nn]32/
[Aa][Rr][Mm]/
[Aa][Rr][Mm]64/
bld/
[Bb]in/
[Oo]bj/
[Ll]og/
[Ll]ogs/

When I run a test in Ignore I get matches for folder names like MyLog, MyObj etc. This is an error because only the suffix in the folder name matches the rules.

Unit test example:

 [Fact]
        public void SimpleIgnore_ObjDir() => GitBasedTest(
           @"""
[Bb]in/
[Oo]bj/
[Oo]ut/
[Ll]og/
[Ll]ogs/
""",
           new[] { "foo/bar", "WpfObj/bar", "MyLog/foo" });

Git will not ignore these folders, but the Ignore code will.

Invalid regex when using double stars

**foo.txt will produce **foo\.txt(/.*)?$ which is not valid:

System.Text.RegularExpressions.RegexParseException
Invalid pattern '**foo\.txt(/.*)?$' at offset 1. Quantifier {x,y} following nothing.

Ingest an existing `.gitignore` file from the disk and then run filters against that

Hello, this class seems awesome and I apologize in advance if my question seems stupid.

I have a repo on the disk, and it has an existing .gitignore file that I want respected. Meaning, parse the .gitignore file and then apply the rules in it. Is there a way to do that?

Might I proceed as the following (pseudo code):

namespace Ignore
{
    public class Ignore
    {
        /*...*/

        public void Ingest(string pathname /*pathname of the .gitignore file*/)
        {
            try
            {
                if (!File.Exists(pathname)) return;
                if (!".gitignore".Equals(Path.GetFileName(pathname)) return;
                
                var lines = File.ReadAllLines(pathname).ToList();
                if (lines == null) return;
                if (lines.Count == 0) return;
                
                Add(lines.ToArray());
            }
            catch(Exception ex)
            {
                /* log the exception or handle it in another fashion */
            }
        }
        
        /* ... */
    }

Listing 1. Proposed methodology for ingesting an existing .gitignore file that is already on the disk.

Would the code above work?

Make it more clear that we should only manipulate relative path

If you pass an absolute path, dependind on the rule it will work correctly or not. It might give the impression that it's ok to use it like that.

Maybe it should throw when the path is rooted?

ignore.IsIgnored("C:\repos\foo.txt"); // => throw
ignore.IsIgnored("\foo.txt"); // => throw
ignore.IsIgnored("foo.txt"); // => OK

Strong Name Assembly

We are building a library in which we are relying on this project. We would like to strong name the library, however this would require to all the dependencies to be strong named as well, which as already mentioned includes this one. It would be the most convenient way for us and it would be a nice benefit for everyone else relying on this project.

In essence to fix this create a .snk file and enter the following command in a Developer Command Prompt for VS:

sn -k ignore.snk

Move the file to the same location as the Directory.Build.props and add the following inside the Directory.Build.props file:

<AssemblyOriginatorKeyFile>$(MSBuildThisFileDirectory)/ignore.snk</AssemblyOriginatorKeyFile>
<SignAssembly>true</SignAssembly>

If you need any further assistance, or want me to create a PR for this feel free to tell me so. Any effort on your end is highly appreciated ๐Ÿ˜„

Differentiate between no match and a negated match

Thanks for the awesome library, I've been using this for years! I'm using Ignore with .gitignore files that I load into it, and I need my code to support nested .gitignore files (e.g. repo/.gitignore and repo/src/.gitignore. There's a way this library could make it easy to support this use case with relatively minor edits. (I know that full nested support is considered out of scope #26 (comment), I also would like to avoid using libgit2sharp)

repo/.gitignore:

*.wasm

repo/src/.gitignore:

!*.wasm

Here's my code:

var ignoresForThisPath = [LoadIgnore("repo/src/.gitignore"), LoadIgnore("repo/.gitignore")];


for(var i = ignoresForThisPath.Count - 1; i >= 0; i--)
        {
            var ignore = ignoresForThisPath[i].Ignore;
            
            var folder = ignoresForThisPath[i].Folder;
            var relativePath = Path.GetRelativePath(folder.FullName, path.FullName)
                .Replace("\\", "/");
            if (ignore.IsIgnored(relativePath) || ignore.IsIgnored(relativePath + "/"))
            {
                return true;
            }
        }

The problem is, the first ignore, which has the negated pattern (!*.wasm) says, the path is not ignored. But I have no way of short-circuiting the checks for parent / ancestor directories. I want to short-circuit the checks because the path is explicitly not ignored. Is there a way we can return an enum from IsIgnored that has values like EXPLICITLY_IGNORED, EXPLICITLY_NOT_IGNORED and NO_RULES_APPLY where NO_RULES_APPLY and EXPLICITLY_NOT_IGNORED would both correspond to the current return value of true? This is a smaller scope than nested ignores, should this be in scope or out do you think?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.