Есть ли недостатки у включения git rerere?

Я читал разные вещи о функции rerere git и подумываю о ее включении.

Функциональность git rerere - это немного скрытая функция. Название расшифровывается как «повторно использовать записанное разрешение» и, как следует из названия, позволяет вам попросить Git вспомнить, как вы разрешили конфликт блоков, чтобы в следующий раз, когда он обнаружил такой же конфликт, Git может решить эту проблему автоматически.

https://git-scm.com/book/en/v2/Git-Tools-Rerere

Но я не видел, чтобы кто-нибудь упоминал о возможных проблемах, которые могут возникнуть при использовании rerere.

Я должен предположить, что есть обратная сторона, иначе она, вероятно, будет включена по умолчанию. Так есть ли обратная сторона включения rerere? Какие потенциальные проблемы это может вызвать, иначе не возникло бы?


git merge git-rerere
person Ryan C. Thompson    schedule 01.04.2011    source источник
comment
Когда включено автоматическое повторное обновление и он применяет предыдущее разрешение, отображает ли оно сообщение? Если да, то как это выглядит? TIA!   -  person joeytwiddle    schedule 19.06.2014
comment
@joeytwiddle, согласно этой статье, это будет формы, Resolved 'index.html' using previous resolution.   -  person    schedule 08.04.2018

Ответы (4)


arrow_upward
76
arrow_downward

Если вы выполните слияние неправильно, затем отмените его, а затем повторите то же слияние, оно снова будет некорректным. Однако вы можете забыть о записанном разрешении. Из документации:

git rerere forget <pathspec>

Это сбрасывает разрешения конфликтов, которые rerere записал для текущего конфликта в <pathspec>.

Будьте осторожны, используя его на определенных путях; Вы же не хотите, чтобы все ваши записанные разрешения были повсюду испорчены. (forget без аргументов был устаревшим чтобы уберечь вас от этого, если вы не наберете git rerere forget . для явного запроса.)

Но если вы не подумаете об этом, вы легко можете добавить это неправильное слияние в свою историю ...

person MatrixFrog    schedule 02.04.2011
comment
Вот почему rerere по-прежнему оставляет файлы с конфликтами, помеченными как не объединенные, так что вам придется вручную добавить их (надеюсь, после их проверки / тестирования) перед фиксацией. Вы всегда можете использовать git checkout -m <path>, чтобы проверить исходную конфликтующую версию и при необходимости повторить разрешение. - person Cascabel; 02.04.2011
comment
В этом есть смысл! Похоже, вам нужен новый псевдоним. - person Cascabel; 02.04.2011
comment
Думаю, это, наверное, главная проблема. Включение rerere добавляет еще один способ неожиданного появления ошибок. Слияние, которое вы прервали (или, скорее, отмените, удалив его из истории), может вернуться и преследовать вас позже. По сути, он вводит второй механизм истории, который ортогонален фактическому графу истории. - person Ryan C. Thompson; 03.04.2011
comment
@RyanThompson Прерванные слияния не влияют на rerere. (Мне часто хотелось, чтобы они делали это - иногда я прерывал слияние, потому что я его неправильно настроил, а затем мне нужно было сделать те же решения, когда я настроил его правильно.) Что касается удаления слияния из истории, зачем вам вообще сделай это? - person Marnen Laibow-Koser; 12.02.2014

arrow_upward
45
arrow_downward

Как упоминает Дж. К. Хамано в своей статье "Fun with rerere"

  • Rerere помнит, как вы решили разрешить конфликтующие области;
  • Rerere также помнит, как вы подправляли за пределами конфликтных регионов, чтобы приспособиться к семантическим изменениям;
  • Rerere может повторно использовать предыдущее разрешение, даже если вы объединяли две ветки с другим содержанием, чем та, которую вы разрешили ранее.

Даже люди, долгое время использующие rerere, часто не замечают последнего момента.

Поэтому, если вы активируете rerere для слишком широкого контента, вы можете столкнуться с неожиданным или сбивающим с толку разрешением слияния из-за последнего пункта.

person VonC    schedule 01.04.2011
comment
Конфликтующие фрагменты все еще должны совпадать; ему довольно сложно дать ложное срабатывание. - person Cascabel; 02.04.2011
comment
И есть git rerere gc забыть старые резолюции. Чем короче временной диапазон, тем меньше вероятность ошибки. - person gavenkoa; 21.03.2021
comment
@gavenkoa True (git-scm.com/docs/ git-rerere # Documentation / git-rerere.txt-emgcem): по умолчанию неурегулированные конфликты старше 15 дней и разрешенные конфликты старше 60 дней удаляются. - person VonC; 21.03.2021

arrow_upward
4
arrow_downward

У меня глобально включен rerere. Я действительно не замечала никаких проблем, и обычно это облегчает мне жизнь.

person Marnen Laibow-Koser    schedule 27.07.2012
comment
То же самое. Никаких проблем за 2+ года использования. - person Andrey Tarantsov; 14.09.2012

arrow_upward
3
arrow_downward

Я Cherry выбрал фиксацию (в gitk), которая содержала только двоичный файл. Cherrypick потерпел неудачу из-за конфликта (что естественно, если подумать), и я разрешил конфликт, сохранив вишневую кирку. Позже я был удивлен, обнаружив в другой ветке с перебазированием, что мои библиотеки DLL не работают - только чтобы обнаружить, что они не были перенесены в перебазирование, поскольку (я предполагаю) автоматическое разрешение конфликтов. Так что это единственный встреченный мной случай (с включенным повторным использованием) столкновения с нелогичным (хотя я уверен, совершенно последовательным) поведением.

person Mr_and_Mrs_D    schedule 31.05.2015
comment
Лечение: git rerere forget path/to/compiled/bin.dll - person Mr_and_Mrs_D; 31.05.2015
comment
В исходном случае конфликт возник не из-за выбора вишни, а из-за перебазирования, но я не думаю, что это имеет значение. - person Mr_and_Mrs_D; 31.05.2015