On Tue, Mar 20, 2018 at 11:22:02PM -0400, Dakota Hawkins 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. Right, I think this gets back to Duy's other email. We're not really recursively applying the pattern, it's just that we don't bother descending into ignore areas at all. > 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. > > What do you think? I think that ignoring all of /ignore-most/ is much more efficient, since we don't have to enumerate the paths inside it at all (which is why the current behavior works as it does). -Peff
