.gitattributes linguist-language (language detection override) isn't taken into account

[ell1e]

Describe the bug
A .gitattributes file's linguist-language entries seem to be ignored. These are language detection overrides based on specified files or file patterns, for use e.g. when a language in the repository is often detected wrong or is unlikely to be known by any tools looking at it. This might for example be the case if it's a small, domain-specific language made just for that specific project.

To Reproduce

1. Clone or create a repo that uses .gitattributes to override something, here is an example line you can put into .gitattributes in your repo root for testing:

   *.mylang linguist-language=MyLang
   

   Then make sure any non-empty stuff.mylang file is present.
2. Run scc on the repository.

Expected behavior
With above steps to reproduce MyLang should show up in the listing, or whatever override is specified. At least when I tried it, this wasn't the case.

Desktop (please complete the following information):

• OS: Fedora Linux
• OS Version 26
• SCC Version: 3.1.0

[boyter]

Dammit wrong issue.

[spenserblack]

IMO supporting linguist-language could be troublesome, because then SCC would have to follow Linguist's language data more closely. Some languages might be in SCC but not Linguist, some might be in Linguist but not SCC, they may have different names, etc.

However, I think the linguist-generated and linguist-vendored boolean attributes are good candidates for SCC.

[ell1e]

Would you really need to, for it to be an improvement? If you just took the name from linguist-language, I think it would already be more correct in many cases. I can't speak on linguist-generated except that it just doesn't seem to provide what I suggested, and it wouldn't correct the incorrect stats on the repos that I work on while linguist-language would.

[spenserblack]

I'm thinking, for example, how linguist has TSX as a separate language, while SCC treats TSX and TypeScript as the same language.

So if a user had something like this:

*.ts linguist-language=TSX

Then that's an unknown language for SCC. So it raises the question of what SCC should do in that case. Should SCC also split TSX into a separate language? Should TSX be an alias of TypeScript in SCC?

And as another example, SCC considers Docker Ignore to be its own language, while Linguist puts it with other Ignore List files. So if I try to tell GitHub/Linguist that my generic RubyOnRails.dockerignore is an ignore file, SCC stats would lose specificity by treating it as a generic ignore file.

---

My comment about linguist-generated may not be appropriate for this exact issue, but I was thinking in terms of a more general "SCC can use linguist-* attributes" idea.

[ell1e]

Oh I see, interesting. I admit I didn't realize there were so many differences, and I get that you're not looking forward to maintaining a mapping table at all times to untangle this. Maybe it could be an option for scc to process linguist-language which defaults to off?

[boyter]

If this were to be done I would be inclined to have scc use its defaults but defer to linguist ones where they are known, falling back to the defaults (with a warning) if thats the case.

[spenserblack]

I get that you're not looking forward to maintaining a mapping table at all times to untangle this.

Oh, I'm just a random user browsing the issues and offering my thoughts, I don't represent the SCC project or its maintainers 😅 Sorry if I made it sound that way.

[boyter]

I get that you're not looking forward to maintaining a mapping table at all times to untangle this.

Oh, I'm just a random user browsing the issues and offering my thoughts, I don't represent the SCC project or its maintainers 😅 Sorry if I made it sound that way.

No I like hearing others ideas.

Generally though I opt for the path of least surprise. What I have described is how I would approach it, based on how I would expect it to work. If someone else has different expectations I want to hear it.