Что я должен / не должен делать при сохранении .emacs и .emacs.d в контроле версий?

Как и многие люди, я управляю многими своими точечными файлами через репозиторий контроля версий (в моем случае Mercurial на Bitbucket, private). Это удобно при настройке новой машины или распространении конфигураций между разными машинами.

Поэтому, естественно, я добавил свой .emacsи .emacs.dк этой настройке.

Затем я установил несколько пакетов и в итоге добавил *.elcсвои .hgignore, точно так же, как я пропускаю *.pycфайлы из моих репозиториев Python.

Есть ли другие вещи, которые я не должен отслеживать, например, сгенерированные файлы, которые специфичны для конкретной среды и не будут полезны / правильны при клонировании на другую платформу? (Я использую Linux и OS X на рабочем столе и FreeBSD на сервере.)

Существуют ли какие-либо приемы настройки, которые обычно используются, чтобы сделать этот вид обмена более ценным? С моей настройкой файла оболочки я все еще ищу хорошие способы, например, выбрать отдельные файлы по веткам.

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

Вот список вещей, которые я не помещаю в систему контроля версий:

Среда указала настройки.

Например, мой Emacs открывает другой файл org при запуске на другом компьютере. Вы не хотите передавать эти настройки в систему контроля версий.

Я использую (require 'local nil t)для загрузки этих настроек, но никогда не фиксирую local.el.

Пакеты, которые управляются менеджером пакетов

Когда пакетами управляет менеджер пакетов, я предлагаю не помещать эти пакеты в систему контроля версий. Потому что :

1. Вы должны совершать после каждого обновления.
2. Вы можете пропустить важный файл, который хранится где-то еще, что делает невозможным правильную синхронизацию на другом компьютере

Вместо фиксации пакетов я предлагаю вам зафиксировать механизм, который распознается вашим менеджером пакетов.

Например, я использую Cask для управления третьими пакетами, поэтому я фиксирую только файл cask, который содержит указанные пакеты, которые я хочу.

Когда я использую package.elранее, моя конфигурация будет проверять, установлен ли пакет / нужно ли его обновлять, поэтому пакет не фиксируется.

Однако , есть некоторые пакеты, которых нет ни в одном репозитории пакетов, в этом случае я передам их в систему управления версиями, например, в site-lisp.

Все файлы, сгенерированные пакетами

Например, все автосохранение, резервное копирование файлов, tramp, eshell, recentf, даже custom.el. Я поместил эти файлы в ~/.emacs/.gen, так что я могу просто игнорировать этот каталог.

Файлы, которые часто изменяются, но должны быть синхронизированы

Например, файл личного словаря, используемый aspellфайловой базой данных. elfeedВ этих случаях я использую Dropbox для синхронизации его на разных компьютерах. Поэтому я не забуду совершить.

Просто убедитесь, что в репозитории нет сгенерированных материалов (например, @ rangi-lin notes) и, если вы делитесь своими точечными файлами с другими, нет связанных с безопасностью вещей (таких как пароли и ключи API). Для последующего я разделил мои настройки в отдельный файл с помощью:

(setq custom-file (concat dotfiles-dir "custom.el"))
(load custom-file 'noerror)

Иногда я перемещаю «безопасные» настройки в большое setqутверждение перед фрагментом выше.

Мой файл .gitignore выглядит так:

/.org-id-locations
/ac-comphist.dat
/auto-save-list
/custom.el
/elpa/*
/image-dired/
/oauth2.plstore
/session.*
/tramp
/url/
/var/
*.elc

ТЛ; др

• использовать .emacs.d/init.elвместо.emacs
• внесите .gitignoreв белый список
• используйте менеджер пакетов

.emacs.d / init.el

Я использую .emacs.d/init.elвместо, .emacsтак как эта настройка позволяет мне поставить .emacs.dпод Git. Наличие ~/.emacsзаставляет вас создать символическую ссылку на git-репозиторий или иметь git-репо в вашем домашнем каталоге. Если вы используете .emacs.d, все решено.

.gitignore

Мой .gitignore - белый список вместо черного списка по умолчанию.

*

!.gitignore
!init.el

Эта конфигурация позволяет вам сконцентрироваться на том, что вам действительно нужно, а не на том, что вам не нужно. .emacs.dне похож на репозиторий исходного кода, это означает, что туда попадает не только ваш код, но и все другие автоматически созданные или временные файлы. Вы на самом деле не знаете, что произойдет. Итак, « игнорируйте все по умолчанию и добавляйте нужные вам файлы » - это лучшая стратегия, ИМО.

Кстати, я сохраняю большую часть конфигурации init.elвместо использования многофайловой схемы. Причина в том, что большой файл позволяет мне: а) использовать стандартные инструменты, такие как occurили, isearch-forwardчтобы перейти к конфигурации, которую я хочу, б) использовать, outshineкоторая делает мой- init.el org-cycleвыполнимым, в) не изменять мой .gitignoreвсе время.

Менеджер пакетов

Если у вас нет особых потребностей синхронизировать версию Emacs и / или версии пакетов во всей вашей системе, не помещайте пакеты в git. Package.elЭто хорошо. use-packageтоже хорошо. Бочка это хорошо. Выберите менеджер пакетов и зафиксируйте только ваш файл конфигурации, но не сам пакет.

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

У меня есть следующие вещи в моем .hgignore

• файл сервера emacs
• файл RecentF: пути к файлам на одной машине не имеют смысла на другой
• Каталог elpa / melpa: Используйте файл инициализации для автоматической установки необходимых пакетов и сохранения времени загрузки / отправки.

Если вы хотите поделиться своим init с другими, вы можете рассмотреть возможность удаления любых файлов истории, например, созданных в режиме savehist. Кроме того, я не думаю, что есть какие-то специальные приемы к этому. Любые правила, которым вы руководствуетесь при разработке версий кода, также хорошо работают здесь

Со временем пакеты добавляют много вещей, ~/.emacsи я заканчиваю тем, что добавляю их один за другим к своему .gitignore. У меня также есть private.elпароли, машинный код и т. Д., Которые я не отслеживаю.

Это то, что у меня есть сейчас.

# Gitignore file

# Remove backup files
*#
*.
*.elc
*~
.#*

# Emacs packages
elpa/
var/

#  Emacs tmp files & Misc
/.mc-lists.el
/.DS_Store
/.emacs.desktop
/.emacs.desktop.lock
/.watsonresults
/ac-comphist.dat
/auto-save-list
/eshell/history
/eshell/lastdir
/newsticker/feeds/
/snippets/
/tramp
/url/cookies
/.python-environments/
/ido.last
/places
/private.el
/games/
/bookmarks
/projectile-bookmarks.eld
/projectile.cache

Это зависит от того, какие пакеты / функции вы используете, поэтому это может быть сложно. Например, помимо файлов, упомянутых Vamsi, если вы используете dired-immage, он создает каталог для кэширования миниатюр. Вы, вероятно, хотите игнорировать также файлы .elc.

Я публикую свой .emacs.d, но использую подпункт с частными изменениями (пароли и тому подобное). Чтобы позволить другим клонировать его, ветвь по умолчанию указывает на вложенный репозиторий, и у каждой машины есть своя именованная ветвь.

При объединении между машинами я сначала graftвносю новые изменения в defaultветку, а затем объединяю defaultветку с другими ветками рабочего места.

Например, вы можете найти мой .emacs.d в bitbucket , включая readme с кратким руководством по использованию.

Возможно, вы захотите добавить драйвер слияния org-mode к этой настройке.

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

1. .elcфайлы (перекомпиляция их при изменении конфигурации является большой проблемой, а ошибки в устаревших elcфайлах часто являются проблемой при отладке).
2. Весь elpaкаталог (и до тех пор, пока закрепление версий не станет стандартным, автоматическая перестройка просто не будет достаточно надежной).
3. Автоматически сгенерированные файлы, такие как eshellистория и gnusфайлы.
4. Частная информация, такая как пароли и ключи API.

(Обратите внимание, что кроссплатформенных проблем нет в списке - должно быть прекрасно иметь одну конфигурацию, которая работает в нескольких операционных системах.) Вместо использования git в качестве решения для синхронизации, я использую его исключительно как решение для отслеживания кода и синхронизировать, используя Dropbox. Таким образом, все надоедливые файлы, которые не должны быть в управлении версиями, позаботятся.

Я же , тем не менее, есть цель иметь моя конфигурация будет REBUILDABLE от источника , если моя конфигурация Dropbox исчезает по какой - либо причине, поэтому я уследить всех установленных пакетов и этажерки в источнике. Моя личная информация также хранится в подмодуле git. Но для повседневной синхронизации git не является отличным решением.