git - вложенность репозиториев

[serzh-z]

Хотелось бы узнать мнения о том, насколько нормальной считается практика вкладывания репозиториев git (каталогов .git) друг в друга.

Пример: есть $HOME/, в корне которого лежит .git. Часть дот-файлов из $HOME/ отправляется в упомянутый репозиторий git. Но есть $HOME/src, в котором есть куча подкаталогов с программными проектами, каждый из которых так же управляется с помощью git.

На первый взгляд - всё работает, то что комитится из $HOME/src/foot/, попадает в $HOME/src/foo/.git и никак не влияет на $HOME/.git, но насколько это хорошая практика и каковы вероятные последствия подобного подхода?

Разделить файлы в $HOME/ и в $HOME/src/ нужно обязательно и хранить их в одном репозитории нельзя, какое ещё может быть решение? Я не нашёл в git возможности установить переменную среды и указать реальное местоположение .git-каталога, где-то за пределеами $HOME.

[Voral]

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

Кроме того стоит быть внимательным. В домашней директории в репе $HOME/.git как много файлов вы туда включили? Как они часто изменяются и как часто вы их комитите. Нет ли шансов нарваться на "коллизию хешей" (описано в "Магия Git" - Приложение А - А.1 Слабости sha1

[watashiwa_daredeska]

насколько это хорошая практика

Всё нормально. У самого уже давным давно так работает :) Git считает корнем репозитория ближайший из родительских каталогов, в котором есть .git. Чтобы логически объединять «вложенные» репозитории, в git есть команда git submodule, хотя эти самые submodule всё равно остаются самостоятельными репозиториями.

Я не нашёл в git возможности установить переменную среды и указать реальное местоположение .git-каталога, где-то за пределеами $HOME.

OPTIONS
--git-dir=<path>
Set the path to the repository. This can also be controlled by setting the GIT_DIR environment variable. It can be an absolute path or relative path to current working directory.
...
ENVIRONMENT VARIABLES
GIT_DIR
If the GIT_DIR environment variable is set then it specifies a path to use instead of the default .git for the base of the repository.

[nickm]

Может воспользоватьзя субмодулями git?
http://book.git-scm.com/5_submodules.html

[serzh-z]

Может воспользоватьзя субмодулями git?

Конфиги в $HOME и копии исходников посторонних свободных проектов в $HOME/src - очень слабо связаны логически. В этом месте мне подмодули не подходят. Но вот в других (скажем, для того, чтобы объеденить конфиги в /etc, свои скрипты в /usr/local и самописные ебилды в /var/db/paludis/repositories/local) это явно то, что нужно.

[nickm]

Хм, но я бы для версионирования конфигов из ~/ возпользовался бы подобным способом - http://github.com/ryanb/dotfiles

Т.е. конфиги лежат в ~/dotfiles, которые рулятся git + скрипт (по ссылке rake task), который бы создавал симлинки на конфиги из ~/dotfiles в ~/

Можно еще тут обсуждение посмотреть - https://bbs.archlinux.org/viewtopic.php?id=73789

имхо, самый православный способ.

[Portnov]

«Самый православный» способ — это держать под управлением git ~/.config, там же все конфиги. Да вот только далеко не все программы такие «православные».

[watashiwa_daredeska]

держать под управлением git ~/.config, там же все конфиги

Не все.

Да вот только далеко не все программы такие «православные».

Угу. А некоторые — настолько уродские, что вперемешку со своими конфигами хранят ещё и кучу вспомогательных данных для ускорения работы (кэш, например).

[serzh-z]

Да вот только далеко не все программы такие «православные».

"Не все" - это очень мягко звучит... "Мало какие, до последних пор" - подходит больше. Ну и, к тому же, ~/.config - это всё же часть проекта Portland, а тот же bash, например, слабо ассоциируется с десктопными приложениями.

Угу. А некоторые — настолько уродские, что вперемешку со своими конфигами хранят ещё и кучу вспомогательных данных для ускорения работы (кэш, например).

Буквально вчера вычищал остатки Midori и, по-правде говоря, как-то не слишком нравится разброс файлов по ~/.cache, ~/.local и ~/.config, вместо одного каталога ~/.midori

Кстати, часто в ужасе представляю, что забудусь и сделаю в $HOME/ нечто подобное "git reset --hard", в результате чего останусь лишь только с одними дотфайлами и вчерашним бекапом. У git нет никакой защиты (средствами конфига, например) от подобного действия?

[watashiwa_daredeska]

У git нет никакой защиты (средствами конфига, например) от подобного действия?

Есть. git commit -a почаще :)

по-правде говоря, как-то не слишком нравится разброс файлов по ~/.cache, ~/.local и ~/.config, вместо одного каталога ~/.midori

А мне очень нравится такая схема у Chrome/Chromium. Можно не выкаблучиваться, а просто git add .config, причем повторять это часто и со вкусом, чтобы установленные/удаленные расширения подхватывались. А у firefox пока по всем профилям прошерстишь и подобавляешь — поседеешь, если скрипт не писать. Скрипт под firefox, скрипт под midori, скрипт под ещё какую-нибудь гадость подобную. Ну их нафиг.

P.S. Это спор из той же оперы, что FHS vs. Program Files. Мне гораздо удобнее, когда верхний уровень структуры каталогов делится по назначению, а не по принадлежности к программе.

[serzh-z]

Есть. git commit -a почаще :)

Перепутал с "git clean" - я её имел в виду. От неё защиты (в плане - вообще запретить) нет?

[watashiwa_daredeska]

От неё защиты (в плане - вообще запретить) нет?

Нет, как и от rm -rf. Однако, git clean просто так не работает, по крайней мере у меня, только с флажком -n или -f, хотя это весьма слабенький foolproof.