2015-03-17 10 views
2

У меня есть родительское репо, содержащее мой проект, и вспомогательное репо, основанное на этом проекте.Слияние из восходящего потока без истории восходящего потока

Родительское репо имеет помеченные выпуски, а вспомогательное репо основывается на одном из этих тегов. Например:

parent v1.0---v2.0---v3.0 
       \ 
       child---[changes] 

К сожалению, когда был создан ребенок репо, родительская история была удалена и репо был реинициализирован с файлами, добавленных с нуля. Таким образом, это означает, что ни одна из истории родительского репо не содержится в дочернем репо, а скорее одна фиксация в начале указывает, что она основана на теге родительского v2.0, где все файлы v2.0 были git add ed.

Есть ли способ использовать Git для объединения восходящих изменений от родительского (например, тега v3.0) обратно в дочерний элемент, несмотря на отсутствие родительской истории?

git pull говорит мне, что нет общих коммитов, поэтому он не знает, с чего начать слияние. Нужно ли переписывать историю ребенка, чтобы добавить историю родителя назад?

Очевидно, что это странно сценарий, и не один я позволю в будущем :)

+0

Можете ли вы показать выход Git pull?Я попытался вытащить из удаленной ветви без каких-либо общих коммитов, и она сливается отлично. –

+0

@JonasBerlin Я думаю, что вы правы на самом деле - извиняетесь, поскольку я действительно пытался сделать патч на изменениях между версиями v2.0 и v3.0, которые не удались. Спасибо, что заставил меня попробовать git pull (и извините за то, что я не написал вопрос правильно, изначально - я просто предположил, что попытка потерпит неудачу, как это сделал патч) – joshschreuder

+0

@JonasBerlin фактически это не делает именно то, что я хотел, и не хотел действительно работают для обновлений - из-за отсутствия истории каждый измененный файл появляется как конфликт слияния. Новые добавленные файлы в порядке, но, очевидно, Git должен иметь возможность разрешать слияния, если для этого есть история. Спасибо, но я думаю, что мой вопрос все еще действителен – joshschreuder

ответ

0

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

Предполагаю, что ветка называется master в обоих случаях.

Итак, сначала мы добавим пульт дистанционное управления для родительского репо и принести его

$ cd /path/to/child/repo 
$ git remote add origin <url_or_path_for_parent_repo> 
$ git fetch origin 

Тогда вы узнали ша из v2.0 тега (тот, с полной историей):

$ git rev-parse v2.0 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

и sha первого фиксации в ветви master, то есть одна со всей версией v2.0, сжатой в одну фиксацию:

$ git checkout master 
$ git log --reverse --format=format:%H | head -n 1 
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 

Затем мы переписываем ветвь master, чтобы поменять родительский bbbbb .. на aaaaa ... (пожалуйста, замените строки bbbbb ... и aaaaa ... в приведенной ниже команде с фактическими результатами выполнения команд выше)

$ git filter-branch --parent-filter 'read p ; if [ "$p" = "-p bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" ]; then echo "-p aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" ; else echo "$p" ; fi' 
Rewrite cccccccccccccccccccccccccccccccccccccccc (d/d) 
Ref 'refs/heads/master' was rewritten 

После этого ваша ветка master должна теперь заменить первую раздавленную фиксацию историей тега v2.0.

Если что-то пошло не так, то можно вернуть master ветвь обратно в исходное состояние с:

$ git reset --hard original/refs/heads/master 

После проверки результатов и счастливы, вы можете избавиться от original/refs/heads/master резервной ветви по:

$ git update-ref -d refs/original/refs/heads/master 

После этого вы сможете просто слить v3.0 тег в master отделение вашего ребенка репо в нормальном режиме.

Смежные вопросы