Re[3]: git два репозитория для одного каталога - Управление проектами

Правильно ли я понимаю, что:
— если в каталоге создать две ветки, каждую ветку привязать к отдельному репозиторию (каждую к своему URL),
— в каждой из веток завести свой .ignorelist который будет инвертным ко второй ветке
то тогда можно будет хранить файлы из одного каталога в двух разных репозиториях ?

Кто-нибудь так делал? Есть в этом подводные камни?

Здравствуйте, B0FEE664, Вы писали:

BFE>- если в каталоге создать две ветки, каждую ветку привязать к отдельному репозиторию (каждую к своему URL),
BFE>- в каждой из веток завести свой .ignorelist который будет инвертным ко второй ветке
BFE>то тогда можно будет хранить файлы из одного каталога в двух разных репозиториях ?

BFE>Кто-нибудь так делал? Есть в этом подводные камни?
.ignorelist в каждый момент времени всё равно будет один в физическом каталоге.
А в чём цель такого наворота? Наверняка можно сделать проще.
Если цель в том, чтобы один каталог хранить в двух репозиториях, то и подключите к нему два репозитория и пушьте в оба.

Здравствуйте, vmpire, Вы писали:

BFE>>- если в каталоге создать две ветки, каждую ветку привязать к отдельному репозиторию (каждую к своему URL),
BFE>>- в каждой из веток завести свой .ignorelist который будет инвертным ко второй ветке
BFE>>то тогда можно будет хранить файлы из одного каталога в двух разных репозиториях ?
BFE>>Кто-нибудь так делал? Есть в этом подводные камни?
V>.ignorelist в каждый момент времени всё равно будет один в физическом каталоге.
.gitignore будет разный в разных ветках

V>А в чём цель такого наворота? Наверняка можно сделать проще.
V>Если цель в том, чтобы один каталог хранить в двух репозиториях, то и подключите к нему два репозитория и пушьте в оба.

Хочу хранить локальные настройки проекта (*.vcxproj.user, *.pro.user.* и т.п.) в отдельном репозитории, чтобы без опаски вызывать git clean -d -n -X .

Здравствуйте, B0FEE664, Вы писали:

BFE>Хочу хранить локальные настройки проекта (*.vcxproj.user, *.pro.user.* и т.п.) в отдельном репозитории, чтобы без опаски вызывать git clean -d -n -X .
Заигрывания с git clean в рабочих директориях всегда в конце концов заканчиваются одним и тем же: потерей данных.

Здравствуйте, Mystic Artifact, Вы писали:

BFE>>Хочу хранить локальные настройки проекта (*.vcxproj.user, *.pro.user.* и т.п.) в отдельном репозитории, чтобы без опаски вызывать git clean -d -n -X .
MA> Заигрывания с git clean в рабочих директориях всегда в конце концов заканчиваются одним и тем же: потерей данных.

как и любое другое удаление файлов.

Здравствуйте, B0FEE664, Вы писали:

BFE>Правильно ли я понимаю, что:
BFE>- если в каталоге создать две ветки, каждую ветку привязать к отдельному репозиторию (каждую к своему URL),
BFE>- в каждой из веток завести свой .ignorelist который будет инвертным ко второй ветке
BFE>то тогда можно будет хранить файлы из одного каталога в двух разных репозиториях ?

BFE>Кто-нибудь так делал? Есть в этом подводные камни?

Поставил эксперимент. git снова не смог.
Более того: переключение с одной ветки на другую и обратно приводит к потере изменений файла !

Содержимое файла testfile2.txt потеряно безвозвратно после:
git checkout repo2_branch
git checkout master

	log
	c:\Temp\test1\repo_1> c:\Temp\test1\repo_1> c:\Temp\test1\repo_1>git --version git version 2.27.0.windows.1 c:\Temp\test1\repo_1>git branch -vv -a * master ae0feee [origin/master] testfile1 — 2 repo2_branch 272cf82 [local_repo2/repo2_branch] delete repo2_file.txt remotes/local_repo2/repo2_branch 272cf82 delete repo2_file.txt remotes/origin/master ae0feee testfile1 — 2 c:\Temp\test1\repo_1>git remote -v local_repo2 file://c:\Temp\repo_2 (fetch) local_repo2 file://c:\Temp\repo_2 (push) origin file://c:\Temp\repo_1 (fetch) origin file://c:\Temp\repo_1 (push) c:\Temp\test1\repo_1>git ls-files .gitignore testfile1.txt c:\Temp\test1\repo_1>git status --ignored --porcelain -s !! testfile2.txt c:\Temp\test1\repo_1>type .gitignore testfile2.txt c:\Temp\test1\repo_1>type testfile2.txt testfile2 — new version c:\Temp\test1\repo_1>git checkout repo2_branch Switched to branch 'repo2_branch' Your branch is up to date with 'local_repo2/repo2_branch'. c:\Temp\test1\repo_1>git ls-files .gitignore testfile2.txt c:\Temp\test1\repo_1>git status --ignored --porcelain -s c:\Temp\test1\repo_1>type .gitignore testfile1.txt c:\Temp\test1\repo_1>type testfile2.txt testfile2 1 c:\Temp\test1\repo_1>git checkout master Switched to branch 'master' Your branch is up to date with 'origin/master'. c:\Temp\test1\repo_1>git ls-files .gitignore testfile1.txt c:\Temp\test1\repo_1>git status --ignored --porcelain -s c:\Temp\test1\repo_1>type .gitignore testfile2.txt c:\Temp\test1\repo_1>dir Volume in drive C is Windows Volume Serial Number is 4CF5-5CB5 Directory of c:\Temp\test1\repo_1 2020-08-07 14:28 <DIR> . 2020-08-07 14:28 <DIR> .. 2020-08-07 14:28 13 .gitignore 2020-08-07 14:28 14 testfile1.txt 2 File(s) 27 bytes 2 Dir(s) 276 013 813 760 bytes free c:\Temp\test1\repo_1>

Вообще говоря это ошибка в git. git не должен затирать новые данные файла содержимым файла из репозитория...

Так же не понятно, зачем удалять локальные файлы, если они находятся в .gitignore, хотя, это, конечно, не ошибка, а фича, но всё равно не приятно.

Здравствуйте, B0FEE664, Вы писали:

BFE>Хочу хранить локальные настройки проекта (*.vcxproj.user, *.pro.user.* и т.п.) в отдельном репозитории, чтобы без опаски вызывать git clean -d -n -X .

Если очень хочется именно в другом репозитории (хоть я лично и не понимаю зачем, ну да ладно), то сделайте hard link нужных файлов в другой каталог и свяжите его с другим репозиторием.
А в основном добавьте их в .gitignore.

Здравствуйте, vmpire, Вы писали:

BFE>>Хочу хранить локальные настройки проекта (*.vcxproj.user, *.pro.user.* и т.п.) в отдельном репозитории, чтобы без опаски вызывать git clean -d -n -X .
V>Если очень хочется именно в другом репозитории (хоть я лично и не понимаю зачем, ну да ладно),

Даже если в том же самом репозитории, но в другой ветке, то что это изменит? Если в одной ветке файл находится в .gitignore, а в другой его в .gitignore нет, то при переключении с ветку на ветку (с первой на вторую), содержимое файла будет затираться версией лежащей во второй ветке.

V>то сделайте hard link нужных файлов в другой каталог и свяжите его с другим репозиторием.
V>А в основном добавьте их в .gitignore.

Раздумываю над этим.

Здравствуйте, B0FEE664, Вы писали:

V>>Если очень хочется именно в другом репозитории (хоть я лично и не понимаю зачем, ну да ладно),

BFE>Даже если в том же самом репозитории, но в другой ветке, то что это изменит? Если в одной ветке файл находится в .gitignore, а в другой его в .gitignore нет, то при переключении с ветку на ветку (с первой на вторую), содержимое файла будет затираться версией лежащей во второй ветке.
Я именно это и имел в виду в прошлом ответе: ".ignorelist в каждый момент времени всё равно будет один в физическом каталоге."

Другое дело, что я вообще не понимаю смысла хранить локальные настройки в отдельном репозитории (или ветке).
Если проект личный, то можно настройки положить в гит вместе с проектом, в тот же репозитории и ветку.
Если проект общий, то общие пользовательский настройки (не относящиеся к проекту) можно держать онлайн, а проектные настройки, которые общие, должны быть всё равнео не в .user файлах.

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

Здравствуйте, vmpire, Вы писали:

V>>>Если очень хочется именно в другом репозитории (хоть я лично и не понимаю зачем, ну да ладно),
BFE>>Даже если в том же самом репозитории, но в другой ветке, то что это изменит? Если в одной ветке файл находится в .gitignore, а в другой его в .gitignore нет, то при переключении с ветку на ветку (с первой на вторую), содержимое файла будет затираться версией лежащей во второй ветке.
V>Я именно это и имел в виду в прошлом ответе: ".ignorelist в каждый момент времени всё равно будет один в физическом каталоге."

В этом-то как раз ничего страшного не было бы, если бы git не затирал локально изменённые файлы из .gitignore. Фактически — это опасная ошибка в git.

V>Если проект общий, то общие пользовательский настройки (не относящиеся к проекту) можно держать онлайн,
Что значит эта фраза? Вот есть какой-то проект, в этом проекте есть файл с абсолютным путём до компилятора. Этот путь на каждой машине свой. Смысла добавлять этот файл в общий проект нет. Где хранить этот файл, если учесть, что такой файл не один. Эти файлы иногда меняется и хочется иметь историю их изменений. Причём в отдельный каталог их не вынести из проекта, так как они создаются сторонними инструментами.

V>Но тут каждый настраивает так, как ему хочется.
V>Гит работает по каталогам, так что можно, как я говорил, использовать под сеттинги отдельный каталог.

Как?

Я вот нашёл одно решение вот тут, но оно несколько корявое, так как получается один и тот же .gitignore, а хочется иметь разные.

Здравствуйте, B0FEE664, Вы писали:

BFE>Правильно ли я понимаю, что:
BFE>- если в каталоге создать две ветки, каждую ветку привязать к отдельному репозиторию (каждую к своему URL),
BFE>- в каждой из веток завести свой .ignorelist который будет инвертным ко второй ветке
BFE>то тогда можно будет хранить файлы из одного каталога в двух разных репозиториях ?

BFE>Кто-нибудь так делал? Есть в этом подводные камни?

Очень интересное решение, я бы даже сказал гениальное.

Проблему будешь озвучивать?

Здравствуйте, VladCore, Вы писали:

VC>Очень интересное решение, я бы даже сказал гениальное.
Гениальное-то оно. конечно, гениальное. Только не работает.

VC>Проблему будешь озвучивать?
Почитайте все ветки.

Здравствуйте, B0FEE664, Вы писали:

V>>Если проект общий, то общие пользовательский настройки (не относящиеся к проекту) можно держать онлайн,
BFE>Что значит эта фраза? Вот есть какой-то проект, в этом проекте есть файл с абсолютным путём до компилятора. Этот путь на каждой машине свой. Смысла добавлять этот файл в общий проект нет. Где хранить этот файл, если учесть, что такой файл не один. Эти файлы иногда меняется и хочется иметь историю их изменений. Причём в отдельный каталог их не вынести из проекта, так как они создаются сторонними инструментами.
Я думал, речь идёт о пользовтельских гастройках типа xxx.csproj.user. Если это настройки компиляции — тут логика другая
Конкретно настройки компиляции я бы решал (да и, собственно, решал) переменными окружения и автоопределением расположения, где такое возможно.

V>>Гит работает по каталогам, так что можно, как я говорил, использовать под сеттинги отдельный каталог.
BFE>Как?
Как я писал ранее: сделать для таких файлов отдельный каталог, файлы туда смапить хардлинками, а этот второй каталог держать в отдельном репозитории.

Здравствуйте, B0FEE664, Вы писали:

V>>Если цель в том, чтобы один каталог хранить в двух репозиториях, то и подключите к нему два репозитория и пушьте в оба.

BFE>Хочу хранить локальные настройки проекта (*.vcxproj.user, *.pro.user.* и т.п.) в отдельном репозитории, чтобы без опаски вызывать git clean -d -n -X .

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.

https://git-scm.com/docs/gitignore

Здравствуйте, 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

Я не понял, чем мне это поможет. Я могу добавить файлы в $GIT_DIR/info/exclude, но разве $GIT_DIR/info/exclude зависит от ветки?

Здравствуйте, vmpire, Вы писали:

V>>>Если проект общий, то общие пользовательский настройки (не относящиеся к проекту) можно держать онлайн,
BFE>>Что значит эта фраза? Вот есть какой-то проект, в этом проекте есть файл с абсолютным путём до компилятора. Этот путь на каждой машине свой. Смысла добавлять этот файл в общий проект нет. Где хранить этот файл, если учесть, что такой файл не один. Эти файлы иногда меняется и хочется иметь историю их изменений. Причём в отдельный каталог их не вынести из проекта, так как они создаются сторонними инструментами.
V>Я думал, речь идёт о пользовтельских гастройках типа xxx.csproj.user. Если это настройки компиляции — тут логика другая
V>Конкретно настройки компиляции я бы решал (да и, собственно, решал) переменными окружения и автоопределением расположения, где такое возможно.

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

V>>>Гит работает по каталогам, так что можно, как я говорил, использовать под сеттинги отдельный каталог.
BFE>>Как?
V>Как я писал ранее: сделать для таких файлов отдельный каталог, файлы туда смапить хардлинками, а этот второй каталог держать в отдельном репозитории.

Но ведь тогда хардлинки будут автоматически удалятся при выполнении команды git clean и каждый раз их придётся восстанавливать.

Здравствуйте, B0FEE664, Вы писали:

BFE>то тогда можно будет хранить файлы из одного каталога в двух разных репозиториях ?
BFE>Хочу хранить локальные настройки проекта (*.vcxproj.user, *.pro.user.* и т.п.) в отдельном репозитории, чтобы без опаски вызывать git clean -d -n -X .

Храните настройки в обычной папке с синхронизацией в облако, типа дроп-бокса или яндекс-диска. Вам же для *.vcxproj.user не нужна история изменений, я так полагаю. Хотя тот же яндекс-диск все равно хранит историю за 14 дней.

Здравствуйте, B0FEE664, Вы писали:

V>>>>Гит работает по каталогам, так что можно, как я говорил, использовать под сеттинги отдельный каталог.
BFE>>>Как?
V>>Как я писал ранее: сделать для таких файлов отдельный каталог, файлы туда смапить хардлинками, а этот второй каталог держать в отдельном репозитории.

BFE>Но ведь тогда хардлинки будут автоматически удалятся при выполнении команды git clean и каждый раз их придётся восстанавливать.
Не должны, вроде, если эти файлы в .gitignore.

Здравствуйте, B0FEE664, Вы писали:

BFE>Правильно ли я понимаю, что:
BFE>- если в каталоге создать две ветки, каждую ветку привязать к отдельному репозиторию (каждую к своему URL),
BFE>- в каждой из веток завести свой .ignorelist который будет инвертным ко второй ветке
BFE>то тогда можно будет хранить файлы из одного каталога в двух разных репозиториях ?

BFE>Кто-нибудь так делал? Есть в этом подводные камни?

Можно при желании сделать два репки: SVN и git

Но лучше снять лыжи и выйти из гамака.

Здравствуйте, Mr.Delphist, Вы писали:

BFE>>Кто-нибудь так делал? Есть в этом подводные камни?
MD>Можно при желании сделать два репки: SVN и git
MD>Но лучше снять лыжи и выйти из гамака.

Ну причём тут лыжи и гамак?
Фактически это обычный сценарий и известная (с 2010-ого года) проблема git : вот описание.
Вот текущее состояние.

Здравствуйте, 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

Здравствуйте, Grelkin, Вы писали:

G>Тем что, имхо, "локальные специфичные для конкретного юзера настройки" и "использование git clean" противоречат друг другу, так как git clean служит для удаления того, что не относится к данному репозиторию. Следовательно, "локальные специфичные для конкретного юзера настройки" становятся уже не совсем локальными и так или иначе будут хранится именно в этом репозитории, например в .gitignore, становясь уже специфичными для конкретного репозитория (но не пользователя) настройками.

Тут нет особых проблем — завести на каждого пользователя свой репозиторий дело не хитрое.

G>Я думаю, что это не очень правильно, и таким артефактам не место в основном репозитории. Поэтому я привел цитату по ссылке выше, где рекомендуется такие файлы помещать даже не в .gitignore, а в info/exclude, тем самым полностью исключая все возможные их следы в основном репозитории.

Так как info/exclude в репозитории не хранится, то кто-нибудь по ошибке обязательно запушит свой локальный файл забыв его вписать в info/exclude.

G>Я бы добавил мои файлы локальных настроек проекта в info/exclude основного репозитория и при необходимости использовал дополнительную команду, создающую ссылки на файлы настроек из основного репозитория во вспомогательный. Например:

С таким же успехом файлы можно просто копировать.

Здравствуйте, B0FEE664, Вы писали:

BFE>Правильно ли я понимаю, что:
BFE>- если в каталоге создать две ветки, каждую ветку привязать к отдельному репозиторию (каждую к своему URL),
BFE>- в каждой из веток завести свой .ignorelist который будет инвертным ко второй ветке
BFE>то тогда можно будет хранить файлы из одного каталога в двух разных репозиториях ?

BFE>Кто-нибудь так делал? Есть в этом подводные камни?

После некоторых исследований (вплоть до чтения кода исходников) оставлю записку, вдруг кому пригодиться.
Общий вывод: подход не очень удобный со множеством подводных камней, но есть решение.
Подводные камни:
1) из-за ошибки в git можно потерять свои исправления безвозвратно тут. (Опция --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 файл, то можно смешать в одном проекте (и каталоге) файлы из двух разных репозиториев, но этот вариант мне не нужен и я его не проверял.

	От:	B0FEE664
	Дата:	06.08.20 17:26
	Оценка:

	От:	vmpire
	Дата:	07.08.20 10:22
	Оценка:

	От:	B0FEE664
	Дата:	07.08.20 11:06
	Оценка:

	От:	Mystic Artifact
	Дата:	07.08.20 11:10
	Оценка:

	От:	B0FEE664
	Дата:	07.08.20 11:48
	Оценка:

От:	Basil2	https://starostin.msk.ru
Дата:	10.08.20 08:20
Оценка:

	От:	Grelkin
	Дата:	09.08.20 09:29
	Оценка:

	От:	Grelkin
	Дата:	12.08.20 08:24
	Оценка: