Подсказки для того, чтобы подвергнуть ~ управлению исходным кодом

То, что я делаю (с теми же целями) должно поместить мои конфигурационные файлы в подкаталог ~/lib и имейте символьные ссылки в моем корневом каталоге, например, .emacs -> lib/emacs/dot.emacs. Я только сохраняю конфигурационные файлы, которые я записал явно при управлении версиями; мой корневой каталог содержит plently автоматически созданных точечных файлов, которые не являются объектом управления версиями. Таким образом ~/lib является объектом управления версиями, и мой корневой каталог не.

У меня есть сценарий, который создает символьные ссылки из файлов под ~/lib. Когда я создаю учетную запись на новой машине, я заполняю ее путем проверки ~/lib и запущение того скрипта.

Мой опыт с CVS, не мерзавцем, таким образом, это не на 100% передаваемо. Одна из причин, я не помещал свой корневой каталог непосредственно под CVS, является этим ~/.cvsignore относился бы ко всему моему контролю CVS и не только моему корневому каталогу; у мерзавца нет этой проблемы. Оборотная сторона того подхода по сравнению с наличием корневого каталога при управлении версиями - то, что Вы не можете использовать git status различать файл, который Вы явно решили проигнорировать (который был бы перечислен в проигнорировать файле, таким образом, не отображенный) и файле, о котором у Вас нет мнения (который был бы отображен с a ?).

Некоторые файлы должны отличаться на различных машинах. Я поместил их в названный каталог ~/Local/SITENAME/lib и или создайте символьные ссылки для них также или (для форматов файлов, которые поддерживают его), имеют включать директиву в файле под ~/lib. У меня также есть символьная ссылка ~/Here -> ~/Local/SITENAME. Так как мерзавец, в отличие от CVS, разработан для поддержки mostly-similar-but-not-identical репозиториев, может быть лучший способ управлять определенными для машины файлами. Несколько моих точечных файлов являются на самом деле не символьными ссылками, но автоматически сгенерированный от содержания под ~/lib и ~/Here.

Я использую старое rcs для этого.

Взгляните на страницы справочника для ci, co, и rcs. Те сайты должны быть полезными также:

• http://www.jodypaul.com/SWE/RCSTutorial/RCSTutorial.html
• http://docstore.mik.ua/orelly/perl/sysadmin/appa_01.htm
• http://tldp.org/HOWTO/RCS.html

Я использую это для версии, управляющей моим dotfiles, например:

ci -u .*vimrc

И если я хочу отредактировать их:

co -l .*vimrc

Я рекомендую делать каталог названным RCS в Вашем ~, можно затем легко скопировать тот каталог где-нибудь.

Я проверяю свои файлы конфигурации к $HOME/.conf/ от BitBucket Подвижный репозиторий. GitHub repo работал бы точно также.

~/.conf контроль содержит файлы конфигурации и сценарий оболочки для заполнения символьных ссылок в $HOME в каждый файл в ~/.conf. Для форматов конфигурации то включение поддержки (.bashrc, .inputrc, .vimrc, и т.д.), я включаю ~/.conf файл, а не ссылка на него, так, чтобы я мог сделать локальные переопределения.

Для некоторых файлов конфигурации I символьных ссылок на файл в моей папке Dropbox и доле с помощью Dropbox.

В течение нескольких месяцев я пытался сохранить $HOME самостоятельно в управлении версиями, но мне усталый от управления крупными черными списками, я усталый от регистрации в изменениях конфигурации, внесенных запущенными приложениями и результатом, даже не был чем-то, что я захочу проверить на другой компьютер. Можно ли предположить фиксировать конфликты ~/.gconf или ~/.config/monitors.xml, или питание fro отличающиеся версии настольных приложений?

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

Я думаю, что Ваша вторая догадка для несвязывания папки при управлении исходным кодом хороша.

Просто добавьте 2 сценария оболочки там. Один для копирования файлов под управлением к ~ и другой для сбора файлов из ~ и скопируйте его назад в управляемую источником папку и фиксацию.

Вот маленький рубиновый сценарий, который я использую для установки новой машины

#!/usr/bin/env ruby
# setup.rb

#list of dirs which you don't want to symlink
ignored = %w(.gitignore .gitmodules misc setup.rb readme)

current_dir = File.expand_path(Dir.pwd)
home_dir = File.expand_path("~")

links = `git ls-tree --name-only HEAD`.lines.map(&:strip).select {|x| !ignored.include?(x)  }

links.each do |link|
  link = File.join(current_dir, link)
  symlink = File.join(home_dir, File.basename(link))
  `ln -ns #{link} #{symlink}`
end

Я только что начал использовать следующий сценарий Python Dotfiles, который является удобным инструментом, который автосвязывает файлы для Вас: https://pypi.python.org/pypi/dotfiles

Мы можем использовать возможность Git для продолжения отслеживания файлов, даже если они перечислены в .gitignore . Итак, этого достаточно для .gitignore :

$ cat .gitignore
/*

Для каждого файла, который вы хотите отслеживать, выполните add -f (параметр -f отменяет игнорирование оба в .gitignore и .git / info / exclude ):

git add -f .gitignore
git add -f .profile
git add -f .zshrc
git add -f .ssh/config

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

git add -f somedirname

Если вы хотите отслеживать весь каталог с всеми новыми файлами , которые появляются в нем, его можно исключить из ] .gitignore способом, описанным в ответе camh :

!/somedirname

Если вы когда-нибудь захотите прекратить отслеживание файла, эта команда удаляет файл из индекса Git, но оставляет его нетронутым на странице жесткий диск:

git rm --cached .ssh/config