Re: .gitattributes override behavior (possible bug, or documentation bug)

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 21, 2018, 16:07 UTC
Message-ID: <CACsJy8A7k0d8wB_XWhvaaTXespg2y6G+Ab4b27Dc3iKY2Zjujw@mail.gmail.com>
In-Reply-To: <CAHnyXxRsqR3A0FpHJwnfOWo29WNx05qWSXfxvmwPv1TUdqm0aQ@mail.gmail.com>

On Wed, Mar 21, 2018 at 4:22 AM, Dakota Hawkins <dakota@dakotahawkins.com> 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.

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