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


107

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


Отображает ли сообщение сообщение, когда автоматическое повторное восстановление включено и применяет предыдущее разрешение? Если да, то как это выглядит? TIA!
joeytwiddle

1
@joeytwiddle, согласно этой статье , это будет форма,Resolved 'index.html' using previous resolution.
sampablokuper

Ответы:


69

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

git rerere forget <pathspec>

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

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

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


13
Вот почему по- rerereпрежнему остаются файлы с конфликтами, помеченными как несвязанные, так что вам придется вручную добавить их (надеюсь, после их проверки / тестирования) перед фиксацией. Вы всегда можете использовать git checkout -m <path>для проверки исходной конфликтующей версии и при необходимости повторить разрешение.
Cascabel

1
В этом есть смысл! Похоже, вам нужен новый псевдоним.
Cascabel

5
Думаю, это, наверное, главная проблема. Включение rerere добавляет еще один способ неожиданного появления ошибок. Слияние, которое вы прервали (или, скорее, отмените, удалив его из истории), может вернуться и преследовать вас позже. По сути, он вводит второй механизм истории, который ортогонален фактическому графу истории.
Райан С. Томпсон

3
@RyanThompson Прерванные слияния не влияют на rerere. (Мне часто хотелось, чтобы они делали это - иногда я прерывал слияние, потому что я его неправильно настроил, а затем мне нужно было сделать те же самые решения, когда я настроил его правильно.) Что касается удаления слияния из истории, зачем вам вообще сделай это?
Marnen Laibow-Koser

40

Как упоминает JC Hamano в своей статье « Fun with rerere »

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

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

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


15
Конфликтующие фрагменты все еще должны совпадать; ему довольно сложно дать ложное срабатывание.
Cascabel


3

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


1
Лечение:git rerere forget path/to/compiled/bin.dll
Mr_and_Mrs_D

В исходном случае конфликт возник не из-за выбора вишни, а из-за перебазирования, но я не думаю, что это имеет значение
Mr_and_Mrs_D
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.