LINUX.ORG.RU

git rebase -p (preserve-merges)

 ,


0

1

добрый день, братья и сёстры!

когда наконец ``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
[при этом — даю изначальное условие — что коммиты — X,Y,Z — содержат исправленные конфликты (вручную).]

делаем:

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, так как требуется ТОЛЬКО УЧАСТОК изменения кода)



отвечаю сам

не́фига делать сложные (ромбовидные, как на первой иллюстрации ascii-art) истории веток. а стараться вместо этого делать делать ветки — линейными :)

импортировать origin (и прочии remote) как ``git pull --rebase`` , и т.. п..

user_id_68054 ★★★★★ ()

tl;dr, однако, возможно тебе пригодится man git-rerere

JackYF ★★★★ ()
Ответ на: комментарий от JackYF

так... поизучал :-)

``git rerere`` — вродебы работает замечательно!

...но только в случае когда всю работу выполняет один и тотже програмист (на одном и томже компьютере)..

..тоесть кажется будто-бы ``rerer`` (а точнее сказать ``rerere`` тут не причём. виноват СТРОГО только ``git rebase -p ...``) не може брать информацию из образцового коммита.. а берёт её только из своего личного кэша.

..хотя даже sha1-номер этого образцового коммита известен (и он высвечивается на экране во время конфликта... его (sha1-номер) даже можно сделать ``git show 1231231blahblahblasha1bla13123`` и там будут конкретные инструкции о том как исправить конфликт)

странно что именно человеку приходится делать ``git show ...`` и смотреть и исправлять, а не ``git rebase -p ...``.. ведь это его работа! :)

user_id_68054 ★★★★★ ()
Ответ на: комментарий от JackYF

или может быть я чего-то напутал?

может ли быть такое что ``rerere`` — СПОСОБЕН всётаки черпать «опыт» из чужих коммитов (сделанным другим программистом, и затем за`fetch`ченные)?

[при специальных условиях, которые я не протестировал???]

user_id_68054 ★★★★★ ()
Ответ на: комментарий от user_id_68054

Не нашёл в документации, но видимо, информация сохраняется локально, что объясняет то, что воспользоваться ею можно только на своём компьютере, и только в качестве повторения того, что уже было ранее разрешено программистом. Вряд ли туда встроили ИИ :)

JackYF ★★★★ ()
Ответ на: комментарий от JackYF

Вряд ли туда встроили ИИ :)

ну тут достаточно не ИИ, а всеголишь например — обработка входящих коммитов во время ``git fetch`` :) :)

но вообще, конешно же, небольшая печаль у меня, от всего этого стресса :-(

user_id_68054 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.