feat(Git): support reading language from git attributes #599
No reviewers
Labels
No labels
Compat/Breaking
Kind
Bad merge
Kind
Bug
Kind
Documentation
Kind
Enhancement
Kind
Feature
Kind
New language
Kind
Security
Kind
Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: mergiraf/mergiraf#599
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "attribute-based-language-selection"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is a continuation of #565, which I'm not allowed to push to directly.
I've added commits to address the points brought up by @ada4a.
There is still the open question of whether we want to honor the linguist gitattributes. It could be tackled here or in a follow-up PR.
read_attribute_for_file
07b3c141b4LangProfile::find_by_filename_or_name
toLangProfile::find
297df690a5LangProfile::find
4f8d5eb724find_impl
I'd still prefer to only use them, because they're kind of the standard -- if your file type doesn't get recognized, it'd be annoying to need to specify both
linguist-language
andmergiraf.language
imolinguist-language
attribute@ada4a wrote in #599 (comment):
Eh. I'm not sure that one would say that
mergiraf
would always be 100% in agreement withlinguist
. For example, saymergiraf
wants to add something like the more specific logic forpyproject.toml
rather than a generictoml
file. If Linguist doesn't differentiate, what couldmergiraf
do?For bundled attributes like this, projects can do:
Yeah, the silly Cake thing is kind of an example for that. Maybe we could look for
mergiraf.language
first, and only thenlinguist-language
I think
mergiraf.language
and then askinglinguist-language
makes sense.@ -97,0 +110,4 @@
.ok()
.filter(|output| output.status.success())?;
// Parse the output of git-check-attr, which looks like:
// <path> COLON SP <attribute> COLON SP <info> LF
Well, it is
NUL
separators here with the-z
flag above.Great! I'll be taking a small holiday from mergiraf, do feel invited to add further changes to this PR (the branch is in the upstream repo so that it's easy for everyone to write to it).
c0e68aac36
to78b80fd4c8
I added support for
mergiraf.language
with fallback tolinguist-language
. Test suite updated to cover it.78b80fd4c8
to60e74cc0b6
@ -97,0 +124,4 @@
.filter(|value| value != "unspecified" && value != "set" && value != "unset")
};
read_attr("mergiraf.language").or_else(|| read_attr("linguist-language"))
This makes two calls to
git check-attr
, but apparentlygit check-attr
supports retrieving multiple attributes at once according to its man page. So I think it would be worth optimizing that further. Leaving that to a follow-up PR.Could you please leave a TODO?
I'll do it directly anyway
linguist-generated=true
#610