.emacs.d：我应该在elpa / archives下控制存档内容文件吗？

Question

I am not sure whether I should version control the following files under my .emacs.d :

[lucas@lucas-ThinkPad-W520]/home/lucas/.emacs.d$ file elpa/archives/marmalade/archive-con
tents                                                                                   
elpa/archives/marmalade/archive-contents: HTML document, UTF-8 Unicode text, with very lo
ng lines, with no line terminators                                                      
[lucas@lucas-ThinkPad-W520]/home/lucas/.emacs.d$ file elpa/archives/gnu/archive-contents
elpa/archives/gnu/archive-contents: ASCII text
[lucas@lucas-ThinkPad-W520]/home/lucas/.emacs.d$ 

As shown above, marmalade/archive-contents is an HTML document while gnu/archive-contents is ASCII text. Are these safe to include in my version control or should I remove them from my index?

For example, I use emacs across different platforms like Ubuntu Linux and Windows 7, and I would like to keep my emacs environment consistent. It works so far, but I want to avoid future problems. I am ignoring files like *.elc , but I don't know whether archive-contents under version control will help or hinder my cross-platform emacs environment.

I looked at other .emacs.d/ repositories, like this one , and examined their .gitignore files, but I don't know if they are doing correctly either. Any suggestions or resources on how to manage the .emacs.d/ version control for cross-platform development would be great.

Here is my current .gitignore :

*~
*.elc
tramp

Update This seems to be an iffy topic, but it seems that the significant majority do not version control their entire elpa/ folder even though it may take a hit on their initial load time (immediately after cloning). I think I will follow that advice, and I'm willing to live with it rather than spending more time managing the extra issues of a pre-compiled repository.

Answer 1

I do not commit .emacs.d/elpa at all. My init.el automatically reinstalls missing packages on startup. I did not have any issues yet, even though I exclusively use unstable packages from MELPA.

Answer 2

I don't think including archive-contents should cause any problems. I don't make much use of package.el, but I have that file in my repo, and haven't noticed any issues.

Byte-compiled .elc files are portable. I recommend that you do include them in your repository, otherwise you risk ending up with uncompiled elisp when you clone your repo, and Emacs will run your config awfully slowly.

Remember that none of the default recompilation commands will compile a .el file if it doesn't already have a .elc file, so you'd be left needing to decide whether or not it was valid to forcibly compile everything (which isn't necessarily a safe thing to do), or manually pick and choose. Neither is a good option.

The exceptions I make are for the elisp files which I edit myself (init file, etc) as there's more chance of causing problems when you're editing files in multiple places, and merging. So I do .gitignore these files (and forcibly compile them for new deployments). However I use http://tarsius.github.com/auto-compile ( Highly recommended) to automatically ensure that the compiled versions of these (and indeed all) .elc files is always up to date, so that when I merge the modified .el files, Emacs won't load the outdated .elc file instead.

FWIW my .gitignore looks like this (although some of the names are custom). It's pretty much a case of adding stuff as you encounter a need for it, though, so I wouldn't suggest that you copy this.

*~
/auto-save-list/
/backup/
/bookmarks.bmk
/desktop/*
/eshell/*
/history
/server/
/tramp
/geben/
/erc/*
/image-dired/
/url
session.*
/my-lisp/*.elc

Answer 3

These files are created by package.el (more specific, the package-update-contents function), and contain the index of packages for each ELPA repository. Checking them into VC might be annoying because they get updated frequently and you have to deal with merge, which is meaningless since they will be updated by package.el eventually.