Add more tests according to gitignore

[karajan1001]

fix #4103

• ❗ I have followed the Contributing to DVC checklist.

• 📖 If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here.

• ❌ I will check DeepSource, CodeClimate, and other sanity checks below. (We consider them recommendatory and don't expect everything to be addressed. Please fix things that actually improve code or fix bugs.)

Thank you for the contribution - we'll try to review it as soon as possible. 🙏

[karajan1001]

Two issues found.

1. Other consecutive asterisks are considered regular asterisks and will match according to the previous rules.

This is an issue of PathSpec.

2. It is not possible to re-include a file if a parent directory of that file is excluded. Git doesn’t list excluded directories for performance reasons, so any patterns on contained files have no effect, no matter where they are defined.

Because paths didn't distinguish with files in dvcignore. So dir/ can't match pathname dir.

[efiop]

@karajan1001 Sorry for the delay. This is outstanding work! Thank you so much for looking into this!

Other consecutive asterisks are considered regular asterisks and will match according to the previous rules.

Should we report it to pathspec and wait for the solution on their side? Or how do you think we should tackle it?

It is not possible to re-include a file if a parent directory of that file is excluded. Git doesn’t list excluded directories for performance reasons, so any patterns on contained files have no effect, no matter where they are defined.

Because paths didn't distinguish with files in dvcignore. So dir/ can't match pathname dir.

Nice catch! So that one is solved and we are doing it the same way gitignore does it, right?

[pared]

One minor thingy. Great idea with citing the .gitignore documentation. Makes it much more understandable.

[pared]

Seems like builds are failing.

[karajan1001]

Should we report it to pathspec and wait for the solution on their side? Or how do you think we should tackle it?

@efiop
I'd like to report it to PathSpec and fix it myself, but only after work could I do it.

Nice catch! So that one is solved and we are doing it the same way gitignore does it, right?
Yes, I had tested with git If the pattern format description is complex or not clear.

Seems like builds are failing.
@pared A bug from pathspec is waiting for fixing.

[efiop]

I'd like to report it to PathSpec and fix it myself, but only after work could I do it.

@karajan1001 Sounds great! 🙏 So maybe let's remove or comment-out that particular test case for now, so we could merge?

[karajan1001]

I'd like to report it to PathSpec and fix it myself, but only after work could I do it.

@karajan1001 Sounds great! 🙏 So maybe let's remove or comment-out that particular test case for now, so we could merge?

@efiop , @pared

There is still something wrong with triple asterisks, According to the document.

Other consecutive asterisks are considered regular asterisks and will match according to the previous rules.

What the result from my computer shows that triple asterisks act like double ones.

Seems that this because the document is changing all the time, and in a previous version

Other consecutive asterisks are considered invalid.

Seems that Git, the documents of gitignore, and Pathspec go different ways. Maybe we should remove the triple asterisks tests, and wait for a stable standard.

And I found another problem. data/* can match data/1/2 just like data/**. This makes conflict with both the documents and the Pathspec

[pared]

Checked latest git master (2.26.0-rc1) and @karajan1001 is right, behavior of x/* is different that explicitly stated in gitignore docs. @karajan1001 that seems like a bug and potential contribution opportunity.

As to current build, I think we should comment out failing ones and wait till it gets done on PathSpec side. As to triple asterisk I would just leave it. If some will ever come to us with valid use case of triple asterisk other than 'match all', then we can consider it. There is no point in blindly following git docs.

[efiop]

Outstanding! Thank you so much @karajan1001 ! 🙏