Меркуриальная проблема с push-уведомлениями

У меня только что возникла проблема с командой hg push. Что я сделал. Во-первых, я создал 2 ветки исправление-1 и исправление-2, внес некоторые изменения в каждую ветку, объединил их обратно в по умолчанию< /strong> и закрыл эти ветки командой:

hg commit --close-branch  

Если я начну hg branches, у меня будет следующий вывод:

default      29:e62a2c57b17c

hg branches -c дает мне:

default                       29:e62a2c57b17c
hot-fix-2                     27:42f7bf715392 (closed)
hot-fix-1                     26:dd98f50934b0 (closed)

Таким образом, hot-fix-* филиалов, похоже, закрыты. Однако, если я попытаюсь внести изменения, у меня появится следующее сообщение об ошибке:

pushing to /Users/user1/projects/mercurial/mytag
searching for changes
abort: push creates new remote branches: hot-fix-1, hot-fix-2!
(use 'hg push --new-branch' to create new remote branches)

и не имеет значения, какую команду я использую, hg push -b . или hg push -b default
Итак, вопрос в том, как я могу отправить эти изменения в репозиторий, не создавая новых веток.

P.S. Раньше я работал с git и надеялся, что подобную модель ветвления можно будет использовать в Mercurial. Спасибо


person Dmytro    schedule 15.03.2011    source источник
comment
Просто скажу прямо в начале: Mercurial может использовать модель ветвления, аналогичную модели git, и использует не именованные ветки, а закладки.   -  person Ry4an Brase    schedule 09.05.2012


Ответы (3)


Во-первых, как указывали многие другие, использование именованной ветки для кратковременной работы не рекомендуется. Именованные ветки предназначены преимущественно для долгоживущих функций или для управления выпусками.

Учитывая, что вы находитесь в этой ситуации, есть несколько доступных вариантов. Все они связаны с изменением истории (поскольку вы, очевидно, пытаетесь изменить что-то, что вы сделали).

Один из них заключается в том, чтобы просто продвигать ветки как есть, учиться на опыте и двигаться дальше. Если остальную часть команды это устраивает, то это случай добавления --new-branch к вашей команде push.

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

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

Я вижу здесь 2 основных подхода. Удалите слияния и перебазируйте свои ветки по умолчанию. Это позволит избавиться от названных ветвей или привить/пересадить ваши изменения. Оба будут одним и тем же конечным результатом, но реализация немного отличается.

Если вы просто хотите использовать graft, теперь это встроенный функция, начиная с HG 2.0. Он заменяет плагин трансплантации, и с ним намного приятнее работать, поскольку он использует ваш обычный инструмент слияния, если возникают конфликты.

Чтобы использовать его, обновитесь до ветки по умолчанию. Затем используйте команду:

hg graft -D "2085::2093 and not 2091"

строка после -D представляет собой запрос выбора версии hg. В вашем случае вам, скорее всего, понадобится только «{start}::{end}», где start — это набор изменений в начале ветки, а end — это конечный набор изменений ветки (игнорируя слияние).

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

Другой вариант — удалить окончательные слияния и использовать команду rebase, которая является частью подключаемого модуля mq.

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

Затем повторите для второй ветки. Теперь у вас должна быть одна длинная ветка с именем по умолчанию.

person Mikezx6r    schedule 15.03.2011
comment
был ответ, который вы хотели, так что это был правильный ответ по определению, но я был бы упущен, если бы не добавил комментарий о том, что большинство рабочих процессов Mercurial предполагают неизменную историю и упорядочивают вещи, чтобы избежать необходимости strip или rebase. В данном конкретном случае это можно сделать, избегая ветвей named для недолговечных сущностей. Если бы эти исправления были анонимными ответвлениями или закладками, вам не пришлось бы переписывать историю с помощью strip или rebase. Построение вашего рабочего процесса на основе инструментов, которые изменяют историю, не является неправильным, просто обычно это не считается передовым опытом Mercurial. - person Ry4an Brase; 16.03.2011
comment
@ Ry4an Полностью согласен. Я сосредоточился строго на вопросе, но должен был упомянуть лучшие практики, чтобы избежать этой ситуации в будущем (и в первую очередь). Спасибо за то, что это было сделано. - person Mikezx6r; 16.03.2011
comment
Спасибо за дополнение. Вскоре я изменю вопрос, чтобы включить изменения в HG. Начиная с 2.0, есть лучшая команда, чем плагин трансплантации. Новая команда — graft, и она предоставляет обычную помощь по слиянию. Пересаживать нет. - person Mikezx6r; 09.05.2012

Просто выполните:

hg push --new-branch

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

См. мой комментарий к вопросу о том, почему именованные ветки лучше всего сохранять для долгоживущих объектов, таких как «стабильные», а анонимные ветки, закладки или клоны больше подходят для недолговечных вещей, таких как исправления и новые функции.

person Ry4an Brase    schedule 16.03.2011

Ваши hot-fix изменения были внесены в ветки. Независимо от того, активна ветка или закрыта, она существует.

Чтобы отправить изменения на сервер (без перезаписи истории), вы должны использовать опцию --new-branch (например, hg push --new-branch`).

Поскольку вы объединили ветки по умолчанию, по-прежнему будет только одна голова (как вы уже видели в своем локальном репо).

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

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

person Tim Henigan    schedule 15.03.2011