Re: .gitattributes override behavior (possible bug, or documentation bug)
- From
Jeff King <peff@peff.net>
- Date
- Mar 21, 2018, 06:52 UTC
- Message-ID
- <20180321065212.GC16784@sigill.intra.peff.net>
- In-Reply-To
- <CAHnyXxRsqR3A0FpHJwnfOWo29WNx05qWSXfxvmwPv1TUdqm0aQ@mail.gmail.com>
On Tue, Mar 20, 2018 at 11:22:02PM -0400, Dakota Hawkins wrote:
Show 19 quoted lines
> 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.
Show 6 quoted lines
> 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