Блог

Я не уверен, должен ли я контролировать версии следующих файлов в моем .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$ 
  

Как показано выше, marmalade/archive-contents это HTML-документ, а gnu/archive-contents это текст ASCII. Безопасно ли их включать в мой контроль версий или мне следует удалить их из моего индекса?

Например, я использую emacs на разных платформах, таких как Ubuntu Linux и Windows 7, и я хотел бы сохранить согласованность моей среды emacs. Пока это работает, но я хочу избежать проблем в будущем. Я игнорирую файлы, подобные *.elc , но я не знаю, archive-contents поможет или помешает ли управление версиями моей кроссплатформенной среде emacs.

Я просмотрел другие .emacs.d/ репозитории, подобные этому, и проверил их .gitignore файлы, но я не знаю, правильно ли они работают. Любые предложения или ресурсы о том, как управлять .emacs.d/ контролем версий для кроссплатформенной разработки, были бы великолепны.

Вот мой текущий .gitignore :

 *~
*.elc
tramp
  

Обновить
Это кажется сомнительной темой, но, похоже, что значительное большинство не контролирует версии всей elpa/ папки, даже если это может повлиять на время их начальной загрузки (сразу после клонирования). Я думаю, что последую этому совету, и я готов смириться с этим, а не тратить больше времени на решение дополнительных проблем предварительно скомпилированного репозитория.

Я вообще не фиксирую .emacs.d/elpa . Мой init.el автоматически переустанавливает отсутствующие пакеты при запуске. У меня пока не возникло никаких проблем, хотя я использую исключительно нестабильные пакеты от MELPA.

Я не думаю, что включение archive-contents должно вызвать какие-либо проблемы. Я не часто использую package.el, но у меня есть этот файл в моем репозитории, и я не заметил никаких проблем.

Скомпилированные в байтах .elc файлы переносимы. Я рекомендую вам включить их в свой репозиторий, иначе вы рискуете получить некомпилированный elisp при клонировании вашего репозитория, и Emacs будет запускать вашу конфигурацию ужасно медленно.

Помните, что ни одна из команд перекомпиляции по умолчанию не будет компилировать .el файл, если у него уже нет .elc файла, поэтому вам придется решать, допустимо ли принудительно компилировать все (что не обязательно безопасно), или вручную выбирать. Ни то, ни другое не является хорошим вариантом.

Исключения, которые я делаю, предназначены для файлов elisp, которые я редактирую самостоятельно (init-файл и т.д.), Поскольку больше шансов вызвать проблемы при редактировании файлов в нескольких местах и слиянии. Поэтому я делаю .gitignore эти файлы (и принудительно компилирую их для новых развертываний). Однако я использую http://tarsius.github.com/auto-compile (Настоятельно рекомендуется) автоматически гарантировать, что скомпилированные версии этих (и действительно всех) файлов .elc всегда актуальны, чтобы при объединении измененных файлов .el Emacs не загружал вместо них устаревший файл .elc.

FWIW мой файл .gitignore выглядит следующим образом (хотя некоторые имена являются пользовательскими). В значительной степени это тот случай, когда вы добавляете материал по мере необходимости, поэтому я бы не советовал вам копировать это.

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

Эти файлы создаются package.el (точнее, package-update-contents функцией) и содержат индекс пакетов для каждого репозитория ELPA. Проверка их в VC может раздражать, потому что они часто обновляются, и вам приходится иметь дело со слиянием, что бессмысленно, поскольку в package.el конечном итоге они будут обновлены.