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

From: Dakota Hawkins <dakota@dakotahawkins.com>
Date: Mar 21, 2018, 07:36 UTC
Message-ID: <CAHnyXxTf16ukf8CFSfzjQjTEjf5yJXFqK5TnS9KiXZEeAD7dgg@mail.gmail.com>
In-Reply-To: <20180321065212.GC16784@sigill.intra.peff.net>

> 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).

That's definitely true, but I wonder what the impact would be for most cases (even for most cases with large repos and larges sets of ignore files).

Most of my .gitignore patterns weren't hand-written (https://www.gitignore.io/ is pretty neat), but there are a ton of patterns like `dir/`...

I think if I were designing it from scratch and knew what I know now I'd probably argue that behavior should be declarative (`dir/* recurse=false` or something), but we can't really get there from here.

At any rate, would it at least be a good idea to make the "trailing slash halts recursion, won't consider nested .gitignore files" explicit in the `.gitignore` doc? Unless I'm missing it, I don't think that behavior is called out (or at least not called out concisely/in one place). It looks like this is all there is:

    "If the pattern ends with a slash, it is removed for the purpose
of the following description, but it would only find a match with a
directory. In other words, foo/ will match a directory foo and paths
underneath it, but will not match a regular file or a symbolic link
foo (this is consistent with the way how pathspec works in general in
Git)."

Also, I'm not sure what the "following description" is in "it is removed for the purpose of the following description". Is that trying to imply "excluded from the rest of the doc"?

- Dakota