Tôi nên / không nên làm gì khi giữ .emacs và .emacs.d trong kiểm soát phiên bản?

Giống như nhiều người, tôi quản lý rất nhiều dotfiles của mình thông qua kho lưu trữ kiểm soát phiên bản (Mercurial trên Bitbucket, riêng tư, trong trường hợp của tôi). Điều này rất hữu ích khi thiết lập một máy mới hoặc truyền cấu hình giữa các máy khác nhau.

Vì vậy, tự nhiên tôi đã thêm .emacsvà .emacs.dthiết lập này.

Sau đó, tôi đã cài đặt một số gói và cuối cùng thêm *.elcvào .hgignore, giống như tôi bỏ qua *.pyccác tệp từ kho lưu trữ Python của mình.

Có những thứ khác tôi không nên theo dõi, ví dụ: các tệp được tạo cụ thể theo môi trường và sẽ không hữu ích / chính xác khi được sao chép sang nền tảng khác? (Tôi sử dụng Linux và OS X trên máy tính để bàn và FreeBSD trên máy chủ.)

Có bất kỳ thủ thuật thiết lập nào thường được sử dụng để làm cho loại chia sẻ này có giá trị hơn không? Với thiết lập tệp shell của tôi, tôi vẫn đang tìm cách tốt để chọn các tệp riêng lẻ trên các nhánh chẳng hạn.

Tôi lưu trữ cấu hình Emacs của mình trong Github vì tôi sử dụng hai máy tính khác nhau, một tại nơi làm việc, một tại nhà.

Đây là danh sách về những thứ mà tôi không đưa vào kiểm soát nguồn:

Môi trường thiết lập quy định.

Ví dụ: Emacs của tôi mở tệp org khác nhau khi khởi động ở máy khác. Bạn không muốn cam kết các cài đặt này vào kiểm soát nguồn.

Tôi sử dụng (require 'local nil t)để tải các cài đặt này, nhưng không bao giờ cam kết local.el.

Các gói được quản lý bởi người quản lý gói

Khi các gói được quản lý bởi người quản lý gói, tôi đề nghị không đưa các gói đó vào kiểm soát nguồn. Bởi vì :

1. Bạn phải cam kết sau mỗi lần cập nhật.
2. Bạn có thể bỏ lỡ tệp quan trọng lưu trữ ở một nơi khác, điều này khiến bạn không thể đồng bộ hóa trên các máy tính khác nhau đúng cách.

Thay vì các gói cam kết, tôi khuyên bạn nên cam kết cơ chế được công nhận bởi người quản lý gói của bạn.

Ví dụ: tôi sử dụng Cask để quản lý các gói thứ 3 của mình, vì vậy tôi chỉ cam kết tệp thùng chứa các gói được chỉ định mà tôi muốn.

Khi tôi sử dụng package.eltrước đó, cấu hình của tôi sẽ kiểm tra xem gói đã được cài đặt / cần cập nhật chưa, vì vậy không có gói nào được cam kết.

Tuy nhiên , có một số gói không tồn tại trong bất kỳ kho lưu trữ gói nào, trong trường hợp này, tôi sẽ cam kết nó với kiểm soát nguồn, chẳng hạn như trong site-lisp.

Tất cả các tệp được tạo bởi các gói

Ví dụ, tất cả các tự động lưu, tập tin sao lưu, tramp, eshell, recentf, thậm chí custom.el. Tôi đặt các tập tin này vào ~/.emacs/.gen, vì vậy tôi có thể bỏ qua thư mục này.

Các tệp thay đổi thường xuyên nhưng bắt buộc phải được đồng bộ hóa

Chẳng hạn như tệp từ điển cá nhân được sử dụng bởi aspell, cơ sở dữ liệu tệp được sử dụng bởi elfeed, Trong những trường hợp này, tôi sử dụng Dropbox để đồng bộ hóa nó trên các máy tính khác nhau. Vì vậy, tôi sẽ không quên cam kết.

Chỉ cần đảm bảo không có nội dung nào được tạo (như ghi chú @ rangi-lin) trong repo và, nếu bạn đang chia sẻ dotfiles của mình với người khác, không có nội dung bảo mật liên quan (như mật khẩu và khóa API). Để sau này tôi đã chia các tùy chỉnh của mình thành một tệp riêng biệt với:

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

Thỉnh thoảng tôi chuyển các tùy chỉnh "an toàn" sang một setqtuyên bố lớn trước đoạn trích ở trên.

Tệp .gitignore của tôi trông như:

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

tl; dr

• sử dụng .emacs.d/init.elthay vì.emacs
• làm cho bạn .gitignoremột danh sách trắng
• sử dụng một trình quản lý gói

.emacs.d / init.el

Tôi sử dụng .emacs.d/init.elthay vì .emacsthiết lập này cho phép tôi đặt .emacs.ddưới git. Có ~/.emacslàm cho bạn để tạo một liên kết tượng trưng đến kho git hoặc để có git repo tại thư mục nhà của bạn. Nếu bạn sử dụng .emacs.d, tất cả đều được giải quyết.

.gitignore

.Gitignore của tôi là danh sách trắng thay vì danh sách đen mặc định.

*

!.gitignore
!init.el

Cấu hình này cho phép bạn tập trung vào những gì bạn thực sự cần thay vì những gì bạn không cần. .emacs.dkhông giống như kho lưu trữ mã nguồn, có nghĩa là không chỉ mã của bạn cư trú mà còn tất cả các tệp tạm thời được tạo tự động hoặc ở đó. Bạn không thực sự biết những gì sẽ đi vào. Vì vậy, " bỏ qua tất cả theo mặc định và thêm các tệp bạn quan tâm " là chiến lược tốt hơn, IMO.

BTW, tôi giữ hầu hết cấu hình trong init.el, thay vì sử dụng lược đồ nhiều tệp. Lý do là một tệp lớn cho phép tôi) sử dụng các công cụ tiêu chuẩn như occurhoặc isearch-forwardchuyển sang cấu hình tôi muốn, b) sử dụng outshinekhiến cho khả năng của tôi init.el org-cycle, c) không thay đổi .gitignoremọi lúc.

Quản lý gói

Trừ khi bạn có nhu cầu đặc biệt để đồng bộ phiên bản Emacs và hoặc phiên bản Gói trên tất cả hệ thống của bạn, không đặt các gói dưới git. Package.elỔn. use-packagecũng tốt Cask là tốt đẹp. Chọn trình quản lý gói của bạn và chỉ cam kết tệp cấu hình của bạn chứ không phải chính gói đó.

I E. Một trong những nhu cầu đặc biệt tôi có thể nghĩ đến là có hai hệ thống, phát triển và triển khai và chúng phải có cùng cấu hình Emacs.

Tôi có những điều sau đây trong .hgignore của tôi

• tập tin máy chủ emacs
• Tệp Recentf: Đường dẫn tệp trên một máy không có ý nghĩa trên máy khác
• thư mục elpa / melpa: Sử dụng tệp init để tự động cài đặt các gói cần thiết và tiết kiệm thời gian kéo / đẩy.

Nếu bạn muốn chia sẻ init của mình với người khác, bạn có thể xem xét xóa bất kỳ tệp lịch sử nào, chẳng hạn như tệp được tạo bởi chế độ lưu trữ. Ngoài ra, tôi không nghĩ rằng có bất kỳ thủ thuật đặc biệt nào cho việc này. Bất kỳ hướng dẫn nào bạn thực hiện cho các dự án mã phiên bản cũng hoạt động tốt ở đây.

Theo thời gian, các gói thêm rất nhiều thứ ~/.emacsvà cuối cùng tôi thêm từng thứ một vào .gitignore. Tôi cũng có một private.elmật khẩu chứa mã, mã máy cụ thể, vv mà tôi không theo dõi.

Đây là những gì tôi có bây giờ.

# 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

Nó phụ thuộc vào gói / tính năng bạn sử dụng, vì vậy nó có thể gặp khó khăn. Bên cạnh các tệp được đề cập bởi Vamsi, ví dụ, nếu bạn sử dụng dired-image, nó sẽ tạo một thư mục ở đó để lưu trữ hình thu nhỏ. Bạn có thể muốn bỏ qua các tập tin .elc quá.

Tôi xuất bản .emacs.d của mình, nhưng sử dụng một subrepo với các thay đổi riêng tư (mật khẩu và như vậy). Để cho phép người khác sao chép nó, nhánh mặc định trỏ đến một subrepo giữ chỗ và mỗi máy đều có nhánh được đặt tên riêng.

Khi hợp nhất giữa các máy, trước tiên tôi graftthay đổi mới vào defaultchi nhánh và sau đó hợp nhất defaultchi nhánh vào các chi nhánh nơi làm việc khác.

Ví dụ: bạn có thể tìm thấy .emacs.d của tôi trên bitbucket , bao gồm cả một readme với hướng dẫn sử dụng ngắn.

Bạn có thể muốn thêm trình điều khiển hợp nhất chế độ org vào thiết lập này.

Sau nhiều lần lặp lại, tôi đã xác định rằng, trong khi kiểm soát phiên bản là tuyệt vời để chia sẻ mã và theo dõi các thay đổi, thì đó không phải là một giải pháp tuyệt vời để đồng bộ cấu hình thay đổi nhanh chóng giữa các máy tính. Lý do là có nhiều thứ nên được đồng bộ hóa và không nên trong kiểm soát phiên bản. Vài ví dụ:

1. .elccác tệp (biên dịch lại chúng khi có thay đổi cấu hình là một rắc rối lớn và các lỗi từ elccác tệp lỗi thời thường gây khó khăn cho việc gỡ lỗi).
2. Toàn bộ elpathư mục (và cho đến khi ghim phiên bản trở thành tiêu chuẩn, tự động xây dựng lại nó không đủ tin cậy).
3. Các tệp được tạo tự động như eshelllịch sử và gnustệp.
4. Thông tin cá nhân như mật khẩu và khóa API.

(Lưu ý rằng các sự cố đa nền tảng không có trong danh sách - sẽ hoàn toàn ổn khi có một cấu hình hoạt động trên nhiều hệ điều hành.) Thay vì sử dụng git làm giải pháp đồng bộ hóa, tôi chỉ sử dụng nó làm giải pháp theo dõi mã và đồng bộ hóa bằng Dropbox. Bằng cách đó, tất cả các tệp gây phiền nhiễu không có trong kiểm soát phiên bản đều được xử lý.

Tôi làm , tuy nhiên, có một mục tiêu của việc có cấu hình của tôi được rebuildable từ nguồn nếu cấu hình Dropbox của tôi biến mất vì lý do gì, vì vậy tôi theo dõi tất cả các gói cài đặt và không có điều gì trong nguồn. Thông tin cá nhân của tôi được lưu trữ trong một mô hình con git là tốt. Nhưng để đồng bộ hóa hàng ngày, git không phải là một giải pháp tuyệt vời.