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

[Eli Zaretskii]

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.