#mercurial #merge
#mercurial #слияние
Вопрос:
Когда я впервые начал использовать hg, update, казалось, обладал почти волшебной способностью принимать недавно извлеченные изменения и интегрировать их в мое локальное хранилище. Однако в последнее время я замечаю, что даже если мои локальные изменения не конфликтуют с недавно извлеченными изменениями откуда-то еще, мне всегда приходится объединять, что приводит к дополнительному набору изменений, который дублирует кучу изменений, которые у меня уже есть в одной из моих локальных строк кода (heads).
Я хочу понять, что заставляет hg требовать слияния, вместо того, чтобы просто сглаживать все изменения вместе с обновлением. Конфликт явно должен требовать слияния. Что еще?
Ответ №1:
Необходимость объединения против обновления зависит не от того, конфликтуют изменения или нет, а от того, есть ли у вас разделение в вашей истории фиксаций. Если у вас есть такая история:
[A]--[B]--[C]--UNCOMMITTEDCHANGESHERE
и вы нажимаете вниз -[D] ваши несогласованные изменения будут объединены с D при обновлении.
Если, однако, вы зафиксировали, чтобы у вас:
[A]--[B]--[C]--[E]
и при извлечении у вас будет:
[A]--[B]--[C]--[E]
-[D]
и вам нужно объединить, чтобы перейти к одной главе.
Для протокола, это идея получше. Обновление с незафиксированными изменениями — это необратимое действие, которое всегда немного пугает. Если вы зафиксировали, вы всегда можете отменить / повторить слияние, пока не будете довольны комбинацией.
P.S. Кто-то, вероятно, собирается предложить fetch расширение, и они абсолютно неправы.
Комментарии:
1. Итак, к соответствующему примечанию — если я перебазирую вместо слияния, сохранится ли при этом одна непрерывная кодовая строка? Я заметил, что hgsubversion требует этого, если вы хотите иметь возможность выполнить возврат к SVN, и это имеет больше смысла в свете этой информации.
2. Перебазирование действительно дает линейную историю, но это немного нечестная линейная история (потому что разработка не была линейной; она была параллельной). Некоторым людям это нравится, но я предпочитаю, чтобы моя история верно и точно отражала порядок, в котором происходили изменения. В конце концов, все зависит от личных предпочтений (или политики команды).
3. Из любопытства, почему выборка «абсолютно неправильная»? Я знаю, что это устарело, но не почему
4. Выборка объединяет 3 совершенно разных действия (
pull,updateиmerge) и одновременно выдает бесполезное сообщение о фиксации. С DVCs перемещение наборов изменений здесь и там (push / pull в mercurial и push / fetch с git) логически отличается от обновления рабочего каталога и объединения заголовков. Когда вы выполняете все 3 с помощью одной команды, вы получаете дерьмовую семантику ошибок, сообщения о неправильной фиксации, и, если вы начинаете, вероятно, возникает путаница в том, какие именно команды изменяют локальные файлы, локальные репозитории и удаленные репозитории.