Как объединить два репозитория Git, один снимок другого с текущей историей?

Мне нужно сделать обратноеэтот вопрос.

Таким образом, почти год назад мы отделили наш репозиторий Git от себя, скопировав текущее состояние обеих веток в новый репозиторий. Чтобы сделать это просто:

<== 2015 Dec              1 Jan                    2016 Jan ==>
Past history, till SVN    New Repo First Commit    All commits to present

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

cd ProjectFull/
git reset --hard # Project was in a branch
git checkout master # Go to master before trying to rebase
git remote add ProjectSplit ../ProjectSplit # New repository is in another directory
git fetch ProjectSplit # Fetch new repository
git cherry-pick <initial commit hash> --strategy-option theirs
git pull --rebase -s recursive -X theirs origin master

Моя идея состояла в том, чтобы выбрать первоначальный коммит нового репо, а затем откатить этот коммит, но это не удалось. Команды, которые я перечислил выше, не выдают ошибку, но они удаляют всю историю старого репозитория.

Вот усеченный журнал моей Git rebase:

$ git rebase origin dev
First, rewinding head to replay your work on top of it...
Applying: Merge branch 'dev' of <REPO> into dev
Using index info to reconstruct a base tree...
<stdin>:298480: trailing whitespace.

<stdin>:298553: trailing whitespace.

<stdin>:298559: trailing whitespace.

<stdin>:298565: trailing whitespace.

<stdin>:298571: trailing whitespace.

warning: squelched 1751272 whitespace errors
warning: 1751277 lines add whitespace errors.
Falling back to patching base and 3-way merge...

CONFLICT (add/add): Merge conflict in <FILE>
Auto-merging <FILE>
CONFLICT (add/add): Merge conflict in <FILE>
Auto-merging <FILE>
CONFLICT (add/add): Merge conflict in <FILE>
Auto-merging <FILE>
CONFLICT (add/add): Merge conflict in <FILE>
Auto-merging <FILE>
CONFLICT (add/add): Merge conflict in <FILE>
Auto-merging <FILE>
<Same>

Failed to merge in the changes.
Patch failed at 0001 Merge branch 'dev' of <REPO> into dev
The copy of the patch that failed is found in:
   ProjectFull/.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

Сценарий в этом ответе не удалось на полпути через старые патчи репо.

Этот ответ работает только для разнородных репозиториев.

 NobleUplift08 авг. 2016 г., 23:39
Извините за поздний ответ @ harmonica141, я не начал работать снова до сегодняшнего дня, и теперь должен быть сделан в ближайшее время, поэтому он снова сфокусирован.
 harmonica14109 авг. 2016 г., 12:42
а) Удалось ли отследить эту пробелную ошибку? б) Содержимое папки, упомянутой вThe copy of the patch that failed is found in: ProjectFull/.git/rebase-apply/patch любой помощи? Что это содержит? Только один коммит там?
 NobleUplift09 авг. 2016 г., 16:49
@ harmonica141 Я не думаю, что ошибки пробелов виноваты. Я сделал много Git-патчей раньше, и они никогда не были проблемой. Я считаю, что проблема сCONFLICT (add/add), который я понятия не имею, что это значит. Кроме того, размер файла патча составляет 5 МБ, поэтому в нем много коммитов.
 harmonica14121 июл. 2016 г., 21:43
Как сбой перебазирования? Любое сообщение? Для меня это похоже на сценарий перебазирования.

Ответы на вопрос(1)

и я, возможно, неправильно понял вопрос и ваше намерение, поэтому я предложу варианты с кратким изложением:

Рассмотрим сшивание репо

Perl CPAN имеет git-stitch-repo,хороший модуль что упрощаетgit fast-export вgit fast-import.

Следует линеаризовать историю.

Опция Subdir

Имейте два директора вместо одного. Или женесколько папок.

Вы уже выполняете процедуру для этого. Откажитесь от финального сбора вишни от вашего вопроса и простоold репо как каталог по текущему.

Наименее хлопотно, просто склеивает репо. Не пытается линеаризовать историю.

Git поддерево слияния

Объединить поддерево это команда Git, более простая в использовании, чем поддеревья и подмодули (и менее тяжелые для администрирования).

Возможно, вам придется использовать--follow при просмотре журнала git для отдельных файлов (после слияния).

Пересмотрите, зачем вам это нужно

Вы уверены, что это будет полезно? Если вы передадите этот старый журнал Git в ELK, подойдет ли индексированный поиск вашим коллегам (и вам)? С возможностью установки некоторых панелей в Kibana? Или если вы установитеgit instaweb на машине со старым репо, чтобы люди могли просматривать ее через Интернет, возможно, она будет соответствовать вашим требованиям?

Рассмотрим git merge-repos

Никогда не пробовал, поэтому не могу рекомендовать, ноэто, видимо, как раз для такого случая и это было написано, когда git-stitch-repo был молод. Может быть стоит проверить.

С некоторым переписать

Существует такжевариант с некоторой историей переписать, с git filter-branch. Вероятно, это можно сделать и с BFG.

 NobleUplift15 авг. 2016 г., 19:59
Я старалсяgit-stitch-repos на прошлой неделе, но в моем хранилище было много слияний между master и dev, так что это не сработало. Далее я попробовалgit merge-repos но он просто помещает обе папки на верхний уровень репо (ProjectFull, ProjectSplit), что не позволило бы мне сохранять историю Full и Split, когда каждая из подпапок для этих репозиториев превращается в свой собственный репозиторий.
 NobleUplift10 авг. 2016 г., 00:31
Я проверю все это завтра утром.

Ваш ответ на вопрос