добрый день, братья и сёстры!
когда наконец ``git rebase -p ...`` — начнёт работать как надо???? (в смысле — чтобы оно делало бы свою работу автоматом — без вмешательства человека, по пустякам).
я про то что хочу, например, «перебазировать» (rebase) ветку, внутри которой есть много замердженных коротких субветок, с сохранением всей структуры этих субветок при перемещении (понятное дело что все sha1-хэши поменяются, но общий вид структуры коммитов должен сохранятся при «перебазировании» на новое место)...
...для этих целей нужна команда
git rebase -p <ветка-куда-крепить> # или ещё какие-нибудь там доп параметры
но в моей версии git (``git version 1.7.7.6``) — процесс повторного мерджинга (возникающий во время выполнения процесса ``git rebase -p ...`` preserve-merges) — видимо — не способен разрешать конфликты, точно таким же образом которым они были УЖЕ ранее разрешены... то есть git просит пользователя разрешить конфликты (``Error redoing merge: 12345blabhabhalSHA1blah54321``), и приходится ОПЯТЬ вручную их разрешать (точно таким же способом которым они УЖЕ были разрешены ранее).
когда этот баг поправят? или уже исправили в новых версиях? кто сталкивался?
...или это не баг а фича? o_0
# p.s.: я не против разрешать конфликты вручную, в случаях когда это действительно нужно, но зачем разрешать один и тот же конфликт несколько раз (одним и тем же способом)?
************************************************************
UPDATE #1:
рисую ascii-art для понятности того чего я хочу:
было:
o---o---o o---o---o o---o---o
/ \ / \ / \
A---B---o---o---o---X---o---o---o---Y---o---o---o---Z---o---C topic
/
D---E---F---G master
делаем:
git rebase -p master topic
станет:
o'--o'--o' o'--o'--o' o'--o'--o'
/ \ / \ / \
A'--B'--o'--o'--o'--X'--o'--o'--o'--Y'--o'--o'--o'--Z'--o'--C' topic
/
D---E---F---G master
и вот я хочу — чтобы полученные коммиты X',Y',Z' — полностью-автоматически (по образцу из — X,Y,Z, без штрихов) исправляли свои конфликты, а не просили делать это человека :-)
************************************************************
UPDATE #2: для чего всё это нужно?
например, у меня проект в котором множество веток:
одна ветка для экспериментальной версии проекта.
другая ветка для стабильной версии проекта.
третья ветка для устаревшей (но ещё пока-что поддерживающейся версии).
ну и ещё допустим ветка для извращённых пользователей (которым с одной стороны хочется стабильности на гране чего-то устаревшего, а с другой стороны хочется некоторых (редких, но сверхъ-удачныхъ) новых плюшек ..
и конечно же — должна быть — и крайне-глючная (полуработающая) ветка в которой концентрируются сверх новые новшества. (назовём эту ветку «developer»)
ветка «developer» имеет крайне-нелинейный вид, так как в неё вливаются (git merge ..., github pull request) различные финтифлюшки, разабатываемые различными программистами.
и время от времени нужно «клонировать» и «пересаживать» участки кода из «developer»-ветки — во все остальные вышеназванные ветки. с разной дозировкой изменений (поэтому — пересаживать — через git cherry-pick, или git rebase. в зависимости от сложности пересаживаемого участка. но точно не через git merge, так как требуется ТОЛЬКО УЧАСТОК изменения кода)