git rerere: не резолвим конфликты дважды

[@Yuretsby]

Интеререресно, спасибо!

[@zatochiSiberian]

Благодарю! Полезно.

[@paulsleepy]

Спасибо, не знал про эту фичу! Обычно в этом кейзе выполняю два мержа - сначала с feature-backend, а только потом с master. Результат тот же.

[@sedovanton781]

git config --global rerere.enabled true
git config --global rerere.autoUpdate true

[@evisotskiydev]

круто, минус одна боль!

[@alexanderm1584]

Прикольно, не знал про шару.

[@DarkKillerBit]

Один раз приходилось пересаживать rerere другому человеку 😅 надо бы тоже попробовать расшарить rerere cache. Спасибо за видео!

[@andrey7829]

Отличное видео, спасибо! Было бы здорово, если бы вы создали плейлист по git как уже есть по vue и docker

[@MaxiManBW]

Крута річ. Почну використовувати на своїх проектах.
Скажи, будь ласка, що за тема для терміналу у тебе стоїть? Хочу собі додати можливість візуалізації `git rebase`

[@evgeniy3370]

А когда планируется Ask me enything?

[@voron121]

Крутая штука, только есть вопрос: допустим порешал конфлик не корректно. Получается что rerere запомнил не корректный резолв и будет шарить это решение на всех участников команды. А есть ли способ отредактировать решение конфликта для rerere ?

[@JavaScriptNinja]

Да. Rerere forget

[@Nixguy]

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

[@vov4egde]

Думаю, потом что ветка feature-frontend будет потом смержена стразу в мастер, а не сначала в feature-backend и уж потом это все в мастер. Как я понял (пожалуйста поправьте если не так) при таком флоу - ребейзить надо относительно той ветки в которую потом все эти фичи будут вливаться. В данном случае - мастер

[@notarobertlangdon]

Почему бы просто не сделать git rebase feature-frontend из feature-backend после разрезолвленного конфликта? И тогда у вас не будет конфликтов. Это надо всегда помнить когда вы делаете цепочные ветки

[@dzen1234]

А мож это черрипик, и ты остальные коммиты не хочешь.

[@404Negative]

наверное потому что это учебный пример по rerere ? всем и так понятно что надо ребейсить от feature-backend. но видео не об этом.

[@notarobertlangdon]

@@404Negative Круто, спасибо что напомнил, спустя 2 года

[@vitaliy.artyukh]

почему тогда git fetch не подтягивает такие важные изменения, а нужны какие-то сторонние решения, вопрос. а про хуки, это прям интересно будет. жду)

[@olehdevua]

> почему тогда git fetch не подтягивает такие важные изменения
потому что это не важные изменения. То что кто-то где-то наресолвил какие-то конфликты, не значит что это нужно всей команде по дефолту, учитывая что эти конликты могут быть поресолвены неверно.
то что тип в видосе начал мутить новую бренчу не с главной, а опираясь на код котовый еще не прошел ревью, говорит о том что не `git rerere` нужен в команду, а процессы.

[@halvamusic]

Можно сразу выходить и сохранять из vim с помощью :x вместо :wq

[@JavaScriptNinja]

Я уже старый переучиваться

[@404Negative]

в vim лучше вообще не заходить

[@Roman23fe]

Как называется эта консоль?

[@NiceDeadPet]

Как называется тема для rsh?

[@Max-nr1bv]

Какие есть минусы. Может ложные срабатывания? Звучит как серебряная пуля, тогда почему эту штуку не включили по дефолту?

[@sashko_guz]

Я думаю, что проблема в том, что ты не все контролируешь, когда автоматический резолв происходит, и через это его не включили по умолчанию