Skip to content

ignore: correct handling of nested rules overriding wild card unignore#5210

Merged
ethomson merged 1 commit intolibgit2:masterfrom
buddhike:master
Sep 9, 2019
Merged

ignore: correct handling of nested rules overriding wild card unignore#5210
ethomson merged 1 commit intolibgit2:masterfrom
buddhike:master

Conversation

@buddhike
Copy link
Copy Markdown

@buddhike buddhike commented Aug 20, 2019

problem:
filesystem_iterator loads .gitignore files in top-down order.
subsequently, ignore module evaluates them in the order they are loaded.
this creates a problem if we have unignored a rule (using a wild card)
in a sub dir and ignored it again in a level further below (see the test
included in this patch).

solution:
process ignores in reverse order.

closes #4963

Copy link
Copy Markdown
Member

@pks-t pks-t left a comment

Choose a reason for hiding this comment

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

Thanks for your PR! The idea seems sensible, and seeing that no tests break is always reassuring with gitignores. I think that we could avoid the newly introduced flag, as I don't see why it shouldn't be set at some point in time. I'm happy to be convinced otherwise if you had specific reasons for it.

src/ignore.c Outdated
if (ignore_lookup_in_rules(out, file, &path)) {
goto cleanup;
}
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think this makes sense to me. There cannot be an ignore rule that is invalidated by its parent rules, but the reverse can be true as demonstrated by your tests. The downside is that we need to always go all the way to the top for files that were ignored in the top-level directory, where we could previously immediately abort in the first iteration.

Naturally, correctness outweighs performance though.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

We could try to work out the starting ignore by taking a minimum of current depth or length of ignores. What do you think?

@buddhike buddhike force-pushed the master branch 2 times, most recently from 893b8b0 to bf2d6c1 Compare August 27, 2019 09:45
problem:
filesystem_iterator loads .gitignore files in top-down order.
subsequently, ignore module evaluates them in the order they are loaded.
this creates a problem if we have unignored a rule (using a wild card)
in a sub dir and ignored it again in a level further below (see the test
included in this patch).

solution:
process ignores in reverse order.

closes libgit2#4963
@buddhike
Copy link
Copy Markdown
Author

@pks-t & @ethomson,
I double-checked the code involved in two scenarios and they are independent. In fact, it has been like that for a long time. I must have observed failing tests due to a local change. Sorry about the confusion and let me know if there's anything else I can do here to help.

@ethomson
Copy link
Copy Markdown
Member

ethomson commented Sep 9, 2019

Seems correct to me. Thanks for the work here @BuddySpike! The ignore functionality is deeply tricky so I'm glad you were able to fix it up for us.

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.

Negate patterns in .gitignore

3 participants