On Wed, Mar 21, 2018 at 4:22 AM, Dakota Hawkins <dak...@dakotahawkins.com> wrote: > Thinking about this a little more, I'm now attracted to the idea that > its .gitignore that's weird. > > As I understand it, .gitignore stops recursion when there's a > directory match (`somedir/`) but also explicitly allows nested > .gitnore file _as well as_ exclusion (`!*.txt`). > > So, in the following (contrived) example, the user doesn't get what they want: > > repo/ > |- .git/ > |- .gitignore # /ignore-most/ > |- ignore-most/ > | |- .gitignore # !*.txt > | |- please_ignore.png > | |- dont_ignore_me.txt > > `repo/ignore-most/dont_ignore_me.txt` is still ignored, despite what > seems like the obvious intention of the user.
Don't get me started on this. I voiced this problem a couple times. Attempted to fix it once which made it to rc cycles and caused lots of regressions. I haven't taken another stab since. > Maybe a unified "best-practices" would first-and-foremost recommend > against matching directories at all (makes sense, git doesn't manage > directories). In the above example, changing `/ignore-most/` to > `/ignore-most/*` has the "desired" effect. I think it's actually more intuitive to think "ignore recursively" (with the trailing slash) These things make sense to you once you know exactly _how_ the matching machinery works. But normal users don't know that. It's probably better that we add recursive matching support in gitattributes. Then both gitignore/gitattr are more or less consistent again and also easy to use (most of the times) -- Duy
