One additional note, I think I was was wrong about this: "In order to match `foo/` directories while allowing for possible later exclusions, consider using a trailing wildcard (`foo/*`). Note that matching directories with a trailing wildcard incurs some additional performance cost, since it requires recursion into subdirectories." `foo/*` will let `!foo/file` work but still seems to prevent `!foo/bar/file`. On Wed, Mar 21, 2018 at 7:53 AM, Dakota Hawkins <dakota@xxxxxxxxxxxxxxxxx> wrote: > First, apologies since I didn't get the in-reply-to correct in my > email header. I'm not sure how to do that (using gmail/gsuite). > > Meant to reply to: > https://public-inbox.org/git/20180321075041.GA24701@xxxxxxxxxxxxxxxxxxxxx/ > >> Just before the context your patch quotes, we have this in gitignore(5) >> already: >> >> [...]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.[...] >> >> I can't see how your change to the documentation doesn't just re-state >> what we already have documented, which is not to say the docs can't be >> improved, but then we should clearly state this in one place, not >> re-state it within the span of a few paragraphs. > > Context: > > This came up originally because of confusion with .gitattributes > patterns, since gitattributes doesn't have the same `foo/` matching > behavior. Jeff King was kind enough to prepare a patch for that > documentation here: > https://public-inbox.org/git/20180320041454.GA15213@xxxxxxxxxxxxxxxxxxxxx/ > > Re-reading the section you quoted again a couple of times you're > correct, but somehow that wasn't clear to me despite reading/searching > for what I wanted to see several times. > > While what I wrote may need improvement, I think there are a couple of > valid concerns with the way this behavior is documented currently: > > - Generally: Reading about pattern matching for .gitignore is > awkward on its face, since positive matches have negative consequences > (in other words `include = !match`). > - Specifically: This behavior that is specific to `foo/` matches is > documented in the section for `!foo` matches. If you're trying to find > the implications of `foo/` you may not have read about `!foo` as > carefully. > > Since this behavior is practically applicable to both pattern formats, > and since patterns in the sum of a repo's .gitignore files can get > somewhat complicated, I think it would be a good idea to either: > > - Do this and basically explain the same behavior twice in two > pattern format sections, or > - Pull the documentation for this behavior out into another section > where users would be likely to find and understand it if they're > looking into either pattern format > > Does that make sense? > > What do you think? > > Thanks for the feedback, > > - Dakota
