Ответ 1

Здесь есть много сценариев, где вы можете это сделать, я сделаю каждый сценарий заголовком, чтобы вы могли найти сценарий, который подходит вашему делу. Обратите внимание, что я все еще изучаю Mercurial, и я бы хотел, чтобы указатели, если то, что я говорю, ошибочно, используя неправильную терминологию, можно было бы сделать лучше и т.д.

Никаких дополнительных изменений, объединение не разделяется (нет нажатий/вытягиваний)

Программист слился, но ничего не сделал, и не имеет (и), что он поделился изменениями с кем-либо, каким-либо образом

В этом случае просто отбросьте локальный клон и получите новый клон из безопасного хранилища.

Локальные изменения сверху слияния, а не общие

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

В этом случае я бы сделал один из четырех:

• Попробуйте использовать расширение REBASE, это приведет к перемещению наборов изменений из одного места в другое. Если изменения основаны на изменениях кода, которые были введены с объединением, необходимо выполнить ручную работу для согласования различий.
• Попробуйте использовать расширение MQ, чтобы вытащить набор изменений, которые должны храниться в очереди исправлений, а затем отбросить их в другом месте. Это, однако, будет иметь ту же проблему, что и расширение REBASE с точки зрения изменений, основанных на слиянии
• Попробуйте использовать расширение TRANSPLANT для "копирования" изменений из одного места в другое. Тем не менее, такая же проблема существует, как и в первых двух.
• Повторите эту работу, возможно, с помощью сложного инструмента, чтобы сделать изменения в наборах изменений, которые я хочу сбросить, и повторить их в правильном месте.

Чтобы избавиться от набора изменений слияния + всех следующих наборов изменений, есть несколько вариантов:

• Используйте команду strip в расширении MQ

  hg strip <hash of merge changeset>
  

• Клонировать и вытащить, а также указать хэш наборов изменений, предшествующих, но не включая слияние. В сущности, создайте новый клон, потянув из поврежденного клона в новый, и избегайте втягивания слияния, которое вы не хотите.

  hg clone damaged -r <hash of first parent> .
  hg pull damaged -r <hash of second parent>
  

Слияние с другими, контроль над клонами

Программист нажал на мастер-репозиторий или кому-то другому, или кто-то вытащил из репозитория программистов. Тем не менее, вы (как в группе разработчиков) управляете всеми репозиториями, так как вы можете общаться и разговаривать со всеми, прежде чем сделать больше работы.

В этом случае я бы посмотрел, можно ли сделать шаг 1 или 2, но это может быть сделано во многих местах, поэтому это может потребовать большой работы.

Если никто не выполнил работу на основе набора изменений слияния, я бы воспользовался шагами 1 или 2 для очистки, затем нажал мастер-репозиторий и попросил всех получить новый клон из главного репозитория.

Сжатие нажата, у вас нет контроля над клонами

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

Игнорируйте набор изменений слияния и работайте в двух ветвях, как будто этого не произошло. Это оставит свисающую голову. Вы можете потом позже, когда вы объедините две ветки, выполните нулевое слияние для этой головы, чтобы избавиться от нее.

  M         <-- this is the one you want to disregard
 / \
*   *
|   |
*   *
|   |

Просто продолжайте работать в двух ветвях:

|   |
*   *
| M |       <-- this is the one you want to disregard
|/ \|
*   *
|   |
*   *
|   |

Затем вы объедините два, реальное слияние, которое вы хотите:

  m
 / \
*   *
|   |
*   *
| M |       <-- this is the one you want to disregard
|/ \|
*   *
|   |
*   *
|   |

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

С TortoiseHg я обновляюсь до слияния, которое я хочу сохранить (верхний, нижний регистр m), затем выберите и щелкните правой кнопкой мыши по оборванной голове слияния ниже, а затем отметьте "Отменить все изменения из цели слияния (другие ) редакция":

Ответ 2

Мы провели эксперимент с "hg backout", поддерживая слияние (не уверен, что это правильный способ сделать это). Затем изменения из ветки 1 удаляются по умолчанию, что хорошо, но мы не можем регенерировать с помощью ветки1.

Я использую резервную копию для отмены слияния. Вы не можете повторить попытку, но вы можете "слить резервную копию", т.е. Когда вы хотите ремикс, вы делаете "hg backout" на "Backed out changeet..." и затем снова объединяете ветвь.

Пример:

  7     M       remerge
  6   /   \
  5   *   |     hg backout 3 (backout backout)
  4   |   *     fix error 
  3   *   |     hg backout 2
  2   M   |     fail merge
    /     \
  1 *     *
    |     |

Ответ 3

Вы не можете сильно компенсировать слияние. ИМО, лучший способ справиться с этим - это просто отказаться от слияния и продолжить цепочку наборов изменений до слияния, оставив свисающую головку (которую можно разделить). Если с момента слияния произошли другие изменения, они могут быть переустановлены на новую "хорошую" голову.

Ответ 4

Этот ответ предполагает, что вы уже нажали

Это приведет к (по крайней мере одной) неразрешенной голове, в зависимости от того, что вы только что забыли. Больше в зависимости от того, кто только что вытолкнул из какой ветки.

Я люблю HG и использую это жадно, но их идея ветки может водить кого-то батти в сочетании с историей, которая (по дизайну) намеренно непреложна.

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

Эрик Раймонд работает над чем-то, что является более или менее агностиком DVCS, который может (надеюсь) помочь в ситуациях, подобных описанным вами, но я не думаю, что он будет поддерживать HG полностью в течение недели или двух. Тем не менее, возможно, стоит посмотреть.

Но, только полезно, если никто не вытащил наконечник "ooopsie".

Ответ 5

Спасибо всем за большой вклад! Поскольку мы были в спешке, чтобы решить проблему, и наша группа относительно нова для Mercurial, мы использовали очень прагматичное решение.

На нашем сервере репозитория мы создали новый репозиторий, затем клонировали старый репозиторий вплоть до пересмотра непосредственно перед слиянием. Затем подтолкнул новый клон на сервер и отправил новую ссылку всем. К счастью, мы довольно небольшая команда разработчиков.

Возможно, не самый лучший способ решить проблему, но он работал:)

Ответ 6

У меня была эта точная проблема. Сотрудник случайно объединил мою ветку в ветку по умолчанию, пока она была еще неполной. Вначале я просто отказался от этого слияния, которое, казалось, работало нормально, пока я не захотел объединить свою ветку в дефолт для хранения. Файлы, которые мне нужны, были помечены для удаления при слиянии.

Решение состояло в том, чтобы полностью вернуться к моей первоначальной версии, которая исправила ошибку моего коллеги и отступила назад. Это остановило файлы, помеченные как удаленные, и позвольте мне успешно объединить мой ветвь по умолчанию.