I have the entire elpa directory added into a git repository so that I always have a known good setup that I can fall back on. This works well when I am cloning it in linux machines but when I clone it in windows machines, it doesn’t work.
I have removed all the .elc files since those are not cross compatible but it still didn’t work and I realise that it’s because the generated autoload file is specified to be using unix style line endings (LF) but when I cloned it in the windows machine, the autoload files will have dos style line endings (CRLF) therefore causing the issue.
Interestingly, the init file also uses CRLF and it still works presumably because it does not have the same specified coding as the generated autoload files.
How should I get around this problem? I’m thinking of setting core.autocrlf to false on my windows machine. While that works, I will have to remember to create new files in my .emacs.d with only LF to keep the git repo clean and also presumably for it to work. I also thought about regenerating those autoloads after a clone but I’m not sure how to do so. Hence, I’m looking to see whether others have better solutions to this problem.
Edit: I realise I can set core.autocrlf to input so that git will automatically convert any CRLF to LF on commit therefore resolving the issue. Regardless, I am still interested to hear from the others who version control their elpa directory on what is their strategy.
Git has some questionable defaults for handling of line endings which differ between linux (/unix), Windows and Mac OS. When using tools which handle line endings the same on all platforms (usually developed for linux initially), you have to set core.autocrlf to false, or it will cause problems.
This git feature is from a time when editors/IDEs on different platforms couldn’t handle different line endings. In the past decade I have never seen a case where the different autocrlf settings solved a problem, but plenty where it caused problems.
Change to
straight.elpackage manager, it downloads git repos you can lock and even add your own.config --global core.autocrlf true
Being the (absolutely idiotic) Windows default, this is more likely the cause of the problems. When working with tools coming from the linux/unix ecosystem this should always be set to false.
Probably not what you want to do, but IIUC you could run Emacs from Cygwin and it wouldn’t have that problem.
I started to play with that to store the eln files on the vc and create a “binary only” emacs …
I don’t know it is theoretically possible or not (to use the eln files without el ones).I only have my
.emacsfile under version control, which automatically installs missing packages throughuse-package’s:ensureparameter.The downside is of course that it takes a while after a fresh checkout.
