markashleybell / mab.dotignore

Check whether a file path should be ignored, based on a .gitignore file.

MAB.DotIgnore

Load and parse .gitignore files (or any text files using the same syntax) to produce an IgnoreList which can be used to ignore specific files and folders during (for example) a recursve file copy operation.

The goal of this library is to implement the same file matching behaviour Git uses to determine which files to ignore when adding to a commit. Please feel free to submit any issues with examples or pull requests, if you find instances where this isn't the case.

Basic usage:

.gitignore file contents

*.txt

C# code

var ignores = new IgnoreList(@"path\to\my\.gitignore");

ignores.IsIgnored(@"path\to\ignore.txt"); // Returns true
ignores.IsIgnored(@"path\to\include.cs"); // Returns false

Example usage

A quick example illustrating how you might integrate an IgnoreList into a copy routine:

public static void CopyWithIgnores(DirectoryInfo source, DirectoryInfo target, IgnoreList ignores)
{
    foreach (DirectoryInfo dir in source.GetDirectories().Where(d => !ignores.IsIgnored(d)))
        CopyWithIgnores(dir, target.CreateSubdirectory(dir.Name), ignores);

    foreach (FileInfo file in source.GetFiles().Where(f => !ignores.IsIgnored(f)))
        file.CopyTo(Path.Combine(target.FullName, file.Name));
}

var source = new DirectoryInfo(@"c:\source");
var destination = new DirectoryInfo(@"c:\destination");

var ignores = new IgnoreList(@"c:\source\.gitignore");

CopyWithIgnores(source, destination, ignores);

Note: this code is not an example of good or efficient recursive copying: it's just here to illustrate the use of this library.

mab.dotignore's Issues

Set up CI

What it says on the tin!

Cloning an ignore list doesn't carry across the match flags

The Clone method doesn't take into account the flags set for each rule it copies over.

Documentation

We need:

• Actual API documentation
• More/better examples (including explanation of relative path requirements)
• Contributor guide (how to get up and running, tests etc)

Strong signing

Hey, great project. However I went to use it as part of a free Visual Studio Extension I've written and VS freaks out because the assembly isn't signed.

Regex performance improvements

Read up on Regex performance:

• https://docs.microsoft.com/en-us/dotnet/standard/base-types/best-practices
• https://www.loggly.com/blog/five-invaluable-techniques-to-improve-regex-performance/
• https://www.moserware.com/2009/03/how-net-regular-expressions-really-work.html
• https://www.regular-expressions.info/catastrophic.html

Improve logging

This needs to be a bit more in-depth to be helpful - group matches by file so that the log for a whole list of files will be readable.

Allow specification of flags when creating IgnoreList

For example, consumers should be able to choose whether the list as a whole is case-sensitive.

Unit tests fail on Linux

Hello, when using this NuGet package I developed on Windows and everything seemed fine on my machine.
But when I run my CI pipeline I noticed that my build is failing on Linux.

Then I tried to run the unit tests inside a Docker container and I noticed that 14 tests fails.

Steps to reproduce:

docker run -it --rm -w "/usr/src/app" mcr.microsoft.com/dotnet/core/sdk:2.1
git clone https://github.com/markashleybell/MAB.DotIgnore
cd MAB.DotIgnore
dotnet build
cd MAB.DotIgnore.Test/
dotnet test

Is this project meant to be cross-platform?

Behavior not coherent with git docs

Hello,

When looking at examples on https://git-scm.com/docs/gitignore#_examples and more precisely:

The pattern "foo/*", matches "foo/test.json" (a regular file), "foo/bar" (a directory), but it does not match "foo/bar/hello.c" (a regular file), as the asterisk in the pattern does not match "bar/hello.c" which has a slash in it.

I noticed it's not working properly with that lib, foo/bar/hello.c will be considered ignored.

[Test]
public void Test_git_example()
{
    var ignoreList = new IgnoreList( new[] {"foo/*"});
    Assert.IsTrue(ignoreList.IsIgnored("foo/bar", pathIsDirectory: true));
    Assert.IsTrue(ignoreList.IsIgnored("foo/test.json", pathIsDirectory: false));
    Assert.IsFalse(ignoreList.IsIgnored("foo/bar/hello.c", pathIsDirectory: false)); // Fails here
}

Benchmarking and performance improvements

There are several shortcuts and optimisations which could be made fairly easily, and would improve performance when dealing with large pattern and file lists:

• When a list is built, remove (or mark as invalid) relative path rules where the parent directory has already been excluded

Add a Filter method

Should accept a list of files/FileInfos/whatever and return a copy of the list with ignored files removed (or modify original list? TBD).

Directory-only matching isn't working

See Dont_Match_File_With_Directory_Rule test

Merge efforts in one C# library

Hello @markashleybell,

I recently stumbled unto another C# library (https://github.com/goelhardik/ignore) for parsing ignore files and I really like the fact that it was testing the behavior against git (using libGit2sharp).

I don't think C# needs more than one library on the subject so I'm opening a friendly discussion to see if/how efforts could be coordinated.

Let me know your thoughts!

Try using unsafe/pointers to exactly copy the original C code?

More of an exercise than an actual necessity, but I'd be interested to see if a) it helps performance (although that's not really an issue anyway) and b) if it sorts out the remaining failing tests

Give base IsMatch method a clearer signature?

Currently we have public bool IsMatch(string path, bool pathIsDirectory), but it does cause a bit of "boolean blindness" unless you label the parameter... for example, without looking at the source, what does the second parameter mean in this case?

rule.IsMatch(directory.FullName, true);

Might be nicer to either replace it with an enum, or make that method internal (or even private) and add IsFileMatch and IsDirectoryMatch methods, so it's really explicit?

Add constructor which allows specification of base directory

If the same ignore list is used at various levels (e.g. solution root and project roots), relative rules do not get applied correctly in child paths (because rules are assumed to be relative to the overall root.

If we allowed a base directory to be passed in, we could dynamically replace the base path in any rules in the list with a forward slash, which would mean the list still worked correctly from within the base path.