Сохранение изменений в движущейся цели (такой как Linux) с помощью git - PullRequest
Новая
       11

Сохранение изменений в движущейся цели (такой как Linux) с помощью git

2 голосов
/ 27 мая 2009

У меня есть набор изменений, которые отлично работают с определенной версией Linux, скажем, 2.6.25.4.

У меня есть дерево мерзавцев, и я создал ветку отслеживания vanilla-2.6.25.4 из тега v2.6.25.4. Я создал ветку под названием my-changes-2.6.25.4 и выполнил всю мою работу.

Теперь я хотел бы перебазировать свою работу поверх произвольной более новой версии Linux. Скажите 2.6.28.9. Каков оптимальный рабочий процесс git для достижения этой цели?

Я знаю, как создать новую ветку из 2.6.28.9, но выполнение чего-то вроде 'git merge my-changes-2.6.25.4' дает всевозможные конфликты из других вещей, которые меня не интересуют. Это кажется сломанным в любом случае.

Я попытался создать новую ветку из моей рабочей my-changes-2.6.25.4 и выполнить git rebase 2.6.28.9, предполагая, что это возьмет мои изменения из 2.6.25.4 и применит их поверх 2.6.28.9, но это дал мне множество конфликтов, которые не были связаны с тем, что я изменил.

Я не уверен, как правильно это сделать. Я использую стабильное дерево linux http://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git, и думаю, что некоторые проблемы могут быть связаны с тем фактом, что версионные теги v2.6.x.y не все из одной линии.

Кто-нибудь знает, как это сделать правильно? Дополнительная заслуга в разработке способа автоматического продвижения вперед, насколько это возможно, с помощью бинарного поиска, чтобы найти следующее место, где Linux сломал мой код, изменив интерфейс, но я представляю, как только я знаю, что на самом деле пытаюсь сделать, я могу автоматизировать это сам .

1 Ответ

2 голосов
/ 27 мая 2009

Ваш второй подход звучит правильно - но как вы вызвали rebase? Вы должны сказать, что вы меняете базовую версию. Я думаю, вам нужно что-то вроде 

# on changes-2.6.25.4
# make new branch
git checkout -b changes-2.6.28.9
# double-check local changes to transport
git log --pretty=oneline v2.6.25.4..
# transport changes to be against new base
git rebase --onto v2.6.28.9 v2.6.25.4
# should now have the same changes
git log --pretty=oneline v2.6.28.9..

Еще одна возможность избежать сброса в середине перебазирования - взять список локальных изменений и вручную добавить их в новую ветку, основанную на v2.6.28.9, с помощью команды "git cherry-pick". На самом деле это фактически то же самое, что и перебазирование, но в некотором смысле дает вам больше контроля над тем, что вы делаете.

Я думаю, что ваши рассуждения о том, почему это проблема, верны: v2.6.28.9 не является потомком v2.6.25.4 - поэтому по умолчанию rebase попытается включить все изменения в v2.6.26 .. v2.6.25.4, как и ваш, если вы просто сделали «git rebase v2.6.28.9». Rebease с одним аргументом попытается получить ваши локальные изменения как «git log $ 1..HEAD», а затем применить их обратно поверх «$ 1» - так что вы можете видеть, что это имеет смысл, только если arg для rebase является ветвью, которая был обновлен Если вы сбросите тот же тег, что и раньше, ничего не произойдет. Если вы перебазируете другой тег, вы будете смешивать изменения других людей с вашими. Вам нужно перебазировать один тег на другой.

...