bug#66255: 29.1; package-generate-autoloads utf-8-emacs-unix coding and git on windows breaks

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 66255 notabug wontfix
> thanks
>
>> From: Robert <robewald@gmx.net>
>> Date: Thu, 28 Sep 2023 12:21:54 +0200
>>
>> When installing packages on emacs 29.1 the interaction with git on
>> windows can lead to breakage.
>>
>> The behaviour can be reproduced on windows with the following steps.
>>
>> - With an empty .emacs.d:
>>   (install-package 'seq)
>>   observe that .emacs.d/elpa/seq-2.24/seq-autoloads.el is created and
>>   coding at the very bottom is set to utf-8-emacs-unix
>>
>> - On the command line inside the directory .emacs.d:
>>   git init
>>   git add -A elpa
>>   git commit -m "testing encodings"
>>   rm -rf elpa
>>   git checkout -f master
>>
>> - now emacs doesn't properly load seq-autoloads.el.  Since git converts
>>   the line endings when writing the file, it now has crlf line endings.
>>   This conflicts with the coding set to utf-8-emacs-unix on the
>>   bottom of the file.  As a result the error message is shown: "File mode
>>   specification error: (user-error Local variables entry is missing
>>   the suffix)".   It is very hard to figure out why this happens.
>
> You must configure Git on Windows not to convert the line endings.
> Nothing else will work reliably on Windows, especially since the Emacs
> Git repository has both files with Unix LF-only EOL format and files
> with DOS/Windows CR-LF EOL format.
>
> Emacs now assumes that Git on Windows was configured not to convert
> EOL format of files when committing or when checking out.
>
>> A workaround is to set git config core.autocrlf false in the .emacs.d
>> repository on windows.  This however is hard to discover.
>
> This is what everyone should do.  (Actually, you should have selected
> that option when you installed Git for Windows.)  I have this set
> globally in my ~/.gitconfig, so it is in effect for all the Git
> repositories on my system.
>
>> If feasible, I suggest to make the default coding system in the autoloads 
>> utf-8 as it
>> used to be.
>
> No, we cannot go back to that, since it produces problems that are
> impossible to solve, see the discussion to which Arash pointed.  Those
> problems are now solved, but te solution assumes that EOL format is
> not changed by Git.

I'm therefore closing this bug report.