Как объединить два репозитория 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".

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

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

Ответ 1

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

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

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

Должен линеаризовать историю.

Опция Subdir

У вас есть два каталога вместо одного. Или несколько dirs.

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

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

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

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

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

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

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

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

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

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

Существует также опция с перепиской истории, с ветвью фильтра Git. Вероятно, это можно сделать и с BFG.