Should Git Attributes be considered part of INI?

[DecimalTurn]

While trying to make Git Attributes show up in the stats bar, I realized that it was actually part of the "INI" group.

https://github.com/github-linguist/linguist/blob/916bd8f3df802fa98b0ea85539e67bd0b88ef158/lib/linguist/languages.yml#L2351C1-L2363C25

Looking back at the PR that introduced this change (#4343) and the related issue (#4335), I see that this comment was made:

We should probably group the corresponding languages under a common parent language.

#4335 (comment)

@pchaigno could you please elaborate on why Git Attributes and Ignore List should be under a common parent language? Couldn't we just let them stand as separate languages?

[DecimalTurn]

There is no official INI standard, but on INI's Wikipedia page, it says that there are 5 stable features:

• Key-value pairs of the form: name = value
• Sections of the form: [Section]
• Case insensitivity for keys (and sections)
• Comments using ;
• Order doesn't matter

Since none of these features are supported^* in Git Attributes and Ignore List, I think we should ungroup them from INI.

@Alhadis I understand why you went with INI when it was proposed that those languages be grouped since it's probably the best (ie. least problematic) option for a parent language, but would you be OK with them standing by themselves?

Related: #4291 (comment)

---

^* Note that:

• name = value can appear in a gitattributes file, but as an attribute (value), not a key-value pair itself.
• Regarding the order, I had to make a test to make sure. If you inverse the following 2 lines, you won't get the same result if you run git check-attr text test.txt. In this case the last row in the file will determine if the text atrtibute is set or not.

*.txt text
test.txt -text  

[Alhadis]

I understand why you went with INI when it was proposed

I don't. By all means, Git Attributes and Ignore List should have been added as standalone languages, as they each have syntaxes distinct from that commonly understood to be INI.

but would you be OK with them standing by themselves?

Absolutely. 👍 Go for it. Not sure what I was thinking in 36f4592.

[DecimalTurn]

Thanks for the response!
What I meant is that if I was held at gunpoint and asked to group them with a data format I'd also choose INI over JSON, YAML, etc.

I'm glad we agree on removing the grouping however. I'll wait for @pchaigno 's comment a little more before going forward just in case.

[Alhadis]

I remember feeling apprehensive about submitting #4343, as it introduced many new language entries for formats that were, for lack of a better word, "unimportant". For some reason, grouping such formats under the umbrella of INI felt like the least "intrusive" way of adding them to GitHub. In hindsight, this was an overabundance of caution on my part, as #4343 was primarily focussed on improving syntax highlighting, not classification accuracy.