On 19.02.24 16:21, Jelte Fennema-Nio wrote:
>> v3-0003-Bring-editorconfig-in-line-with-gitattributes.patch
>>
>> I question whether we need to add rules to .editorconfig about files
>> that are generated or imported from elsewhere, since those are not meant
>> to be edited.
> I agree that it's not strictly necessary to have .editorconfig match
> .gitattributes for files that are not meant to be edited by hand. But
> I don't really see a huge downside either, apart from having a few
> extra lines it .editorconfig. And adding these lines does have a few
> benefits:
> 1. It makes it easy to ensure that .editorconfig and .gitattributes stay in sync
> 2. If someone opens a file that they are not supposed to edit by hand,
> and then saves it. Then no changes are made. As opposed to suddenly
> making some whitespace changes
>
> Attached is a new patchset with the first commit split in three
> separate commits, which configure:
> 1. Files meant to be edited by hand)
> 2. Output test files (maybe edited by hand)
> 3. Imported/autogenerated files
> diff --git a/.gitattributes b/.gitattributes
> index e9ff4a56bd..7923fc3387 100644
> --- a/.gitattributes
> +++ b/.gitattributes
> @@ -1,3 +1,4 @@
> +# IMPORTANT: When updating this file, also update .editorconfig to
match.
Everybody has git. Everybody who edits .gitattributes can use git to
check what they did. Not everybody has editorconfig-related tools. I
tried the editorconfig-checker that you had mentioned (I tried the Go
version, not the JavaScript one, because the former is packaged for
Homebrew and Debian), but it was terrible and unusable. Maybe I'm
holding it wrong. But I don't want users of a common tool to bear the
burden of blindly updating files for a much-less-common tool. This is
how we got years of blindly updating Windows build files. The result
will be to that people will instead avoid updating .gitattributes.
ISTM that with a small shell script, .editorconfig could be generated
from .gitattributes?