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

From: Dakota Hawkins <dakota@dakotahawkins.com>
Date: Mar 20, 2018, 04:25 UTC
Message-ID: <CAHnyXxQMbnNam=oB_B57xDZBaMPRn_8hfKtostHPV6nBHbTBog@mail.gmail.com>
In-Reply-To: <20180320040411.GB12938@sigill.intra.peff.net>

> Right. The technical reason is mostly "that is not how it was designed,
> and it would possibly break some corner cases if we switched it now".

I'm just spitballing here, but do you guys think there's any subset of the combined .gitignore and .gitattributes matching functionality that could at least serve as a good "best-practices, going forward" (because of consistency) for both? I will say every time I do this for a new repo and have to do something even slightly complicated or different from what I've done before with .gitattributes/.gitignore that it takes me a long-ish time to figure it out. It's like I'm vaguely aware of pitfalls I've encountered in the past in certain areas but don't remember exactly what they are, so I consult the docs, which are (in sum) confusing and lead to more time spent trying/failing/trying/works/fails-later/etc.

One "this subset of rules will work for both this way" would be awesome even if the matching capabilities are technically divergent, but on the other hand that might paint both into a corner in terms of functionality.

Show 11 quoted lines

>> > I think just "/.readme-docs/**" should be sufficient for your case. You
>> > could also probably write "*" inside ".readme-docs/.gitattributes",
>> > which may be simpler (you don't need "**" there because patterns without
>> > a slash are just matched directly against the basename).
>>
>> Wouldn't that make the "*" inside ".readme-docs/.gitattributes",
>> technically recursive when "*" matches a directory?
>
> Sort of. The pattern is applied recursively to each basename, but the
> pattern itself does not match recursively. That's probably splitting
> hairs, though. :)

I understand, but if I think about it too much I feel the overwhelming urge to stop thinking about it :)

Show 11 quoted lines

>> It's always seemed to me that both were necessary to explicitly match
>> things in a directory and its subdirectories (example, IIRC: "git
>> ls-files -- .gitattributes" vs "git ls-files -- .gitattributes
>> **/.gitattributes"). Maybe that example is peculiar in that its a
>> dotfile and can't have a wildcard before the dot?
>
> Those are pathspecs, which are not quite the same as gitattributes. They
> don't do the magic basename matching.
>
> For pathspecs a "*" matches across slashes, which is what allows "git
> log -- '*.h'" to work (but not a suffix wildcard like 'foo*').

Same comment -- makes sense but hard to want to think too much about.

Show 10 quoted lines

>> I guess my takeaway is that it would be _good_ if the gitattributes
>> documentation contained the caveat about not matching directories
>> recursively, but _great_ if gitattributes and gitignore (and whatever
>> else there is) were consistent.
>
> I agree it would be nice if they were consistent (and pathspecs, too).
> But unfortunately at this point there's a maze of backwards
> compatibility to deal with.
>
> -Peff

Again, as above, what if there were a subset of functionality git could recommend to avoid inconsistencies?