Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, Mr.Delphist, Вы писали:
BFE>>>Кто-нибудь так делал? Есть в этом подводные камни?
MD>>Можно при желании сделать два репки: SVN и git
MD>>Но лучше снять лыжи и выйти из гамака.
BFE>Ну причём тут лыжи и гамак?
BFE>Фактически это обычный сценарий и известная (с 2010-ого года) проблема git : вот описание.
BFE>Вот текущее состояние.
Если вот прямо очень важный файл, то
1) его надо тоже где-то хранить, но в другом репозитории
2a) специальным батником подкладывать всё необходимое для гарантированного билда в нужное место
2b) если технически возможно, то изменить билд, чтобы он мог использовать тот файл из внешнего по отношению к git-бранчу источника
Обычно у себя такие штуки держу в каком-то левом change set, чтобы он не попал в рабочий коммит (привет многим тулчейнам на основе eclipse, ну а VS уже давно не болеет такой бякой)
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, Grelkin, Вы писали:
V>>>>Если цель в том, чтобы один каталог хранить в двух репозиториях, то и подключите к нему два репозитория и пушьте в оба.
BFE>>>Хочу хранить локальные настройки проекта (*.vcxproj.user, *.pro.user.* и т.п.) в отдельном репозитории, чтобы без опаски вызывать git clean -d -n -X .
G>>G>>Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file.
G>>https://git-scm.com/docs/gitignore
BFE>Я не понял, чем мне это поможет. Я могу добавить файлы в $GIT_DIR/info/exclude, но разве $GIT_DIR/info/exclude зависит от ветки?
Тем что, имхо, "локальные специфичные для конкретного юзера настройки" и "использование git clean" противоречат друг другу, так как git clean служит для удаления того, что не относится к данному репозиторию. Следовательно, "локальные специфичные для конкретного юзера настройки" становятся уже не совсем локальными и так или иначе будут хранится именно в этом репозитории, например в .gitignore, становясь уже специфичными для конкретного репозитория (но не пользователя) настройками.
Я думаю, что это не очень правильно, и таким артефактам не место в основном репозитории. Поэтому я привел цитату по ссылке выше, где рекомендуется такие файлы помещать даже не в .gitignore, а в info/exclude, тем самым полностью исключая все возможные их следы в основном репозитории.
Я бы добавил мои файлы локальных настроек проекта в info/exclude основного репозитория и при необходимости использовал дополнительную команду, создающую ссылки на файлы настроек из основного репозитория во вспомогательный. Например:
~/sample % tree -a -L 2
.
├── settings
│ ├── .git
│ └── user.settings
└── wdir
├── file
├── .git
└── user.settings -> ../settings/user.settings
и
~/sample/wdir % git clean -f -X
Removing user.settings
~/sample/wdir % ln -s ../settings/user.settings user.settings
Здравствуйте, B0FEE664, Вы писали:
BFE>Правильно ли я понимаю, что:
BFE>- если в каталоге создать две ветки, каждую ветку привязать к отдельному репозиторию (каждую к своему URL),
BFE>- в каждой из веток завести свой .ignorelist который будет инвертным ко второй ветке
BFE>то тогда можно будет хранить файлы из одного каталога в двух разных репозиториях ?
BFE>Кто-нибудь так делал? Есть в этом подводные камни?
После некоторых исследований (вплоть до чтения кода исходников) оставлю записку, вдруг кому пригодиться.
Общий вывод: подход не очень удобный со множеством подводных камней, но есть решение.
Подводные камни:
1) из-за ошибки в git можно потерять свои исправления безвозвратно
тутАвтор: B0FEE664
Дата: 07.08.20
. (Опция --no-overwrite-ignore должна использоваться по умолчанию для git checkout _имя_ветки_, но в последней версии по умолчанию --overwrite-ignore).
2) даже если бы ошибки не было, есть трудность с переключением между ветками: каждое переключение между ветками придётся делать одновременно со слиянием.
Решение (только для работы из командной строки) для случая, когда в одном репозитории хранится неполный список файлов из второго репозитория:
Вместо различных веток использовать различные репозитории.
Сделать это можно так:
берём два репозитория и делаем их клоны в два каталога. После чего удаляем из второго (не основного) репозитория все файлы оставляя только подкаталог .git.
В первом клоне/репозитории/каталоге работаем как обычно, а для работы со вторым используем специальные переменные окружения GIT_DIR и GIT_WORK_TREE.
Присвоив в GIT_DIR путь к подкаталогу второго репозитория (включая .git), а в переменную GIT_WORK_TREE путь до файлов первого репозитория, можно работать со файлами так, как будто работа производится из второго репозитория. Затруднение при этом в том, что .gitignore один и тот же для обоих репозиториев, но это не проблема, потому, что даже если файл находится в .gitignore списке с ним всё равно можно работать, как если бы его в списке не было. Для этого достаточно один раз его добавить в репозиторий используя ключ -f для команды git add. Если файл был добавлен в репозиторий, то его наличие в списке .gitignore игнорируется, поэтому с его версинированием нет проблем.
Пример:
Пусть файла из первого репозитория лежат в
C:\repo_1\
Пусть файлы из первого репозитория лежат в
C:\repo_2\
тогда:
cd C:\repo_1\
set GIT_DIR=
C:/repo_2/.git
set GIT_WORK_TREE=
C:/repo_1
PROMPT $Cgit:%GIT_DIR%$H$H$H$H$F$S$L$Q$G$S[$P]$_git$G
git status
— отобразит статус файлов лежащих в C:\repo_1\ для репозитория repo_2. (PROMPT изменён исключительно для удобства.)
Подозреваю, что если вместо .gitignore использовать $GIT_DIR/info/exclude файл, то можно смешать в одном проекте (и каталоге) файлы из двух разных репозиториев, но этот вариант мне не нужен и я его не проверял.
