Принудительное нажатие на новую голову, когда уже вытащили все изменения

Можно ли принудительно создать новую удаленную головку при нажатии?

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

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

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

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


person Marcin Wisnicki    schedule 13.02.2012    source источник


Ответы (3)


Вы можете использовать опцию --force для принудительного создания новой головы.

Опция --new-branch используется для именованной ветки, в вашем случае речь идет об анонимной ветке.

Причина, по которой «подсказка перемещена», заключается в том, что вы недавно объединили набор изменений. Делая это, нет никакого способа сделать то, что вы хотите.

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

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

person krtek    schedule 13.02.2012

Вы не можете сохранить tip при отправке: это псевдотег, который всегда указывает на новейший набор изменений в репозитории. Концепция tip устарела в Mercurial, потому что tip может менять значение более или менее случайным образом в зависимости от порядка нажатия — как вы видели.

Единственный способ создать новую голову — это, ну, создать ее :-) Под этим я подразумеваю, что вам нужны две головы — одна с вашими изменениями и одна с основным кодом, который вы хотите, чтобы колледжи тянуть и сливаться с. Имея только одну голову (та, которую вы получили после выполнения hg merge), нет никакого способа подать сигнал колледжам, что им не следует ее использовать.

Намного лучше использовать отдельный репозиторий на сервере. Перейдите в программное обеспечение для управления репозиторием и создайте ветку для ваших изменений. Затем настаивайте на этом и скажите своим колледжам, чтобы они рассмотрели это. Они возьмут ваш клон и просмотрят изменения. Если они им нравятся, то они могут объединиться с основным кодом и перейти в обычное репо. Если им не нравятся изменения, они могут выбросить свой локальный клон, удалить наборы изменений или, может быть, просто откатить запрос.

person Martin Geisler    schedule 14.02.2012

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

Я думаю, что закладки hg нуждаются в тонкой настройке, прежде чем они станут похожими на ветки git, но процесс, который я описываю, во многом совпадает с тем, что объясняется в закладки Mercurial кикстартера.

Например, если у вас сейчас ревизия 250.

echo >>README
hg ci -m "enabling bookmark branch_xyz"
hg book my-tip # optional but nice to have
hg book -r 250 branch_xyz
hg up branch_xyz
# hack ... hack hack
hg ci -m "awesome feature xyz (in progress)"
hg push -fB branch_xyz 

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

person Pykler    schedule 21.01.2013
comment
Я согласен, что закладка, по крайней мере, в таких инструментах, как Eclipse, нуждается в некотором TLC. Это действительно раздражает, когда у вас есть несколько головок с закладками, и Eclipse спрашивает при каждом обновлении, хотите ли вы объединиться. - person Adam Gent; 02.05.2013