git автоматически переименовывать объединенные файлы

Question

Я хочу создать репозиторий, который является комбинацией двух существующих репозиториев.

Два репо в основном отсоединены, однако есть несколько метафайлов, которые отображаются в обоих репозиториях, в основном .gitignore, .gitattributes и README.md.

следующее будет в основном воспроизводить мою ситуацию.

mkdir repoa 
cd repoa 
git init 
touch .gitignore 
touch README.md 
mkdir adir 
touch adir/afile 
git add -A 
git commit -m"repoa" 

mkdir repob 
cd repob 
git init 
touch .gitignore 
touch README.md 
mkdir bdir 
touch bdir/bfile 
git add -A 
git commit -m"repob" 

mkdir repoab 
cd repoab 
git init 
git remote add repoa /path/to/repoa 
git remote add repob /path/to/repob 
git pull repoa master 
git pull repob master 

На этом этапе мы получим сообщение о конфликте.

Есть ли какой-нибудь способ, между git init для repoab и git pull о том, что я могу сказать repoab автоматически переименовать README.md из repoa в READMErepoa.md и README.md от repob до READMErepob.md.

Дополнительная сложность возникает при использовании файлов .gitignore. По существу файл .gitignore в repoab должен быть комбинацией repoa/.gitignore с repob/.gitignore, а также некоторыми правилами для repoab. Идеальный сценарий здесь заключается в том, что я использую ту же стратегию переименования, что и для файлов README.md, repoa/.gitignore становится repoab/.gitignorerepoa, аналогичным для repob. Затем, если есть какой-то способ включить файлы в repoab/.gitignore.

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

Еще один зверь - это файлы .gitattribute, я бы искал объединение трех файлов (repoa/.gitattributes + repob/.gitattributes + repoab/.gitattributes). Здесь также может быть полезна папка .gitattributes.

Итак, проблема в том, что у меня есть несколько таких простых разрешений конфликтов. Нельзя объединять файлы один раз. Однако я собираюсь в конечном итоге с теми же конфликтами каждый раз, когда я выхожу из любого репо. Я не уверен, что у меня также возникнут проблемы, потому что для выполнения repoab/.gitignore будет добавлена ​​версия .gitignore repoab перед repoa и repob.

---

Update: пример того, где я думаю, что это своего рода управление мета-файл может быть полезным

Предположим, что у меня есть приложение, моделируемого MVC с помощью следующего простого дерева каталогов.

myapplication/ 
--README.md 
--.gitignore 
--.gitattributes 
--main.p 
--model/ 
----myapplication.m 
--view/ 
----myapplication.v 
--control/ 
----myapplication.c 
--plugins/ 

Это приложение работает и выполняет foo, но также позволяет добавлять плагины.

Я разработал myapplication, чтобы вы могли создать плагин без изменения какого-либо кода для myapplication, когда он будет запущен, main.p будет захватывать любые плагины, которые он находит в каталоге плагинов, плагины будут нести ответственность за свои собственные файлы модели/представления/управления.

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

myapplication/ 
--README.md 
--.gitignore 
--.gitattributes 
--model/ 
----plugina.m 
--view/ 
----plugina.v 
--control/ 
----plugina.c 
--plugins/ 
----plugina.p 

Теперь я создаю новый репозиторий, который будет использоваться для разработки и тестирования плагина.

Этот репозиторий - это слияние myapplication и plugin, созданное в той же усадьбе, что и я создал repoab выше. Здесь у меня есть слияния конфликты с .gitignore и README.md

myapplication/ 
--README.md (CONFLICT with plugina/myapplication) 
--.gitignore (CONFLICT with plugina/myapplication) 
--.gitattributes 
--main.p 
--model/ 
----myapplication.m 
----plugina.m 
--view/ 
----myapplication.v 
----plugina.v 
--control/ 
----myapplication.c 
----plugina.c 
--plugins/ 
----plugina.p 

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

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

Весь этот рабочий процесс просто сдерживается довольно тривиальным препятствием для этих конфликтов постоянного слияния.

Answer 1

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

Ближайшая вещь, которую вы можете получить, это использовать Git submodules. Это позволяет помещать repo A и repo B в подкаталоги в repo AB. Они остаются полностью независимыми в этих подкаталогах, но репо AB поддерживает свое состояние - в основном, AB отслеживает, какая версия каждого из них проверена.