перебазирование сильно слитой ветки перед тем, как отправить изменения вверх по течению - PullRequest
Новая
       20

перебазирование сильно слитой ветки перед тем, как отправить изменения вверх по течению

1 голос
/ 21 марта 2011

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

A--B--C--D--b'-E--F--e'--G--H          (svn)
 \     \        \           \
  a--b--c--d--e--f--g--h--i--j         (mine)

То есть, upstream содержит изменения от e, а моя ветвь содержит все изменения от upstream.Теперь я хотел бы перейти к 

A--B--C--D--b'-E--F--e'--G--H
                             \
                              a--b--d--f'-g--h--i

(где f 'будет то, что останется от разрешения слияния вручную).Дополнительные трудности включают переименование в ветке svn, за которым я также следовал в одном из коммитов слияния, где моя ветвь содержит изменения в файле как до, так и после слияния.

Любая идея, как разумно сделать это?Очевидное git rebase -m svn mine не совсем сокращает его, так как не может обнаружить переименования и задает множество вопросов о конфликтах в строках, где кончик моей ветви имеет то же содержимое, что и ветка восходящего направления.

1 Ответ

1 голос
/ 21 марта 2011

вы можете попытаться (просто дикая догадка): 

git rebase -i --onto H a j
# then remove all commits you don't want (already cherry-picked)
# hope the best :D

другая возможность, в зависимости от количества коммитов, заключается в том, чтобы выбрать каждый коммит по отдельности.я думаю, что более новые версии git могут даже диапазоны коммитов cherry-pick, но я не уверен в этом, хотя

...