Я - пользователь git, смущенный ветвлением mercurial. Как я должен отслеживать небольшие изменения?


32

Я всегда использовал git раньше, но я хочу внести свой вклад в python, поэтому теперь я должен изучать Mercurial, и я нахожу это очень расстраивающим.

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

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

  • TortoiseHG и hg logдо сих пор показывают, что commit и defaultbranch имеют 2 головы. И если я правильно понимаю, вы не можете удалить коммиты в hg без дополнительных плагинов.

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

  • Я сделал это hg updateпосле того, как потянул, чтобы masterавтоматически переместить мою закладку в последний коммит, но я не смог найти способ сделать это в TortoiseHG.

Что я делаю не так? Это нормально и ожидаемо, и я должен просто игнорировать эти проблемы? Или как мне работать с моими ветками?

Ответы:


22

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

Просто клонируйте их хранилище и работайте в нем, а затем сделайте запрос на извлечение.

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

У Mercurial есть целая страница в вики, описывающая различные способы « обрезки мертвых веток ». Опция «Использование клонирования» должна соответствовать вашим требованиям.

Чтобы ответить на ваши более конкретные вопросы ...

TortoiseHG и журнал hg по-прежнему показывают, что ветвь commit и default имеет 2 заголовка. И если я правильно понимаю, вы не можете удалить коммиты в hg без дополнительных плагинов.

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

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

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

Не беспокойтесь о номерах ревизий. Они удобны, не более. Хеш-коды являются важными идентификаторами, которые будут передаваться из репо в репо. Номера версий не совпадают в разных хранилищах. Проверьте Hg Init для хорошего объяснения.

Номера ревизий - это просто удобный и запоминающийся ярлык при работе с одним репо.

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

При использовании TortoiseHG используйте Workbench, а не другие инструменты. Все (почти) там. Обновление в контекстном меню ревизии. Это не всегда интуитивно понятно, но по приведенной выше ссылке есть хорошее руководство, и, как только вы к нему привыкнете, вы в конечном итоге нажмете на кнопку с уверенным отказом.


Я, конечно, видел аргумент до того, что правильно названные ветви означают, что история редактирования менее необходима в hg
jk.

9

Видимо, есть 4 способа обработки ветвления в Mercurial. 1 и 4 показались мне совершенно нелепыми, названные ветви кажутся тяжеловесными

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

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

TortoiseHG и журнал hg по-прежнему показывают, что ветвь commit и default имеет 2 заголовка.

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

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

Вы вообще не можете ничего удалить в Mercurial, и вам не следует этого делать . Вы можете использовать, hg stripно это не записано - вы просто отключили часть вашего локального репо. Вы не можете это подтолкнуть, и если вы извлечете из репо, в котором есть ветвь, которую вы разделили локально, она вернется.

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

Числа ничего не значат. Вы можете игнорировать их, если они вас смущают.

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

Я не использовал TortoiseHG, но hg pull -uсделаю и то, pullи другое update.

Я всегда использовал git раньше, но я хочу внести свой вклад в python, поэтому теперь я должен изучать Mercurial, и я нахожу это очень расстраивающим.

Это нормально, многие пользователи Mercurial чувствуют то же самое по отношению к Git (включая меня).


6

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

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

Во-первых, попытка пролить немного света на некоторые вещи, которые вы упоминаете:

  • 1 и 4 считаются ветвлением, потому что каждый раз, когда вы фиксируете, вы фактически создаете неназванную ветвь (если к тому же времени есть другой коммит в вашем исходном / благословенном репо), который технически является ветвью. В методе 4 вы создаете новую «голову», а в методе 1 - нет . Главы должны быть объединены. Я согласен, что метод 1 довольно глуп, но некоторым он нравится ... для небольших проектов, я думаю.

  • Что касается метода 2, дело не в том, что ветви тяжелые, а в том, что они постоянны . Вы не можете удалить ветку, если не используете что-то вроде расширения полосы. Опять же, философия дизайна Mercurial не направлена ​​на изменение истории (но она стала лучше).

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

Теперь, чтобы ответить на ваши другие вопросы:

  • Вы можете проверить, какие у вас есть головы hg heads, если вы видите 2+ головы в одной названной ветви, желательно, чтобы они были объединены. Это, вероятно, где ваша закладка .
  • Чтобы избавиться от только что внесенной вами ревизии, вы можете это сделать hg rollback, но я полагаю, что это не так.
  • Чтобы удалить закладку, просто сделайте hg bookmark --delete yourbookmark
  • Вы будете счастливы, что в истории легко рубить ветки. Посмотрите на расширение Rebase и операцию Strip .
  • Mercurial уже поставляется в комплекте с несколькими расширениями, но они не активированы по умолчанию . Просто зайдите в любую папку и щелкните правой кнопкой мыши в любом месте, чтобы получить контекстное меню TortoiseHG, зайдите в Глобальные настройки и затем Расширения: активируйте расширение MQ и расширение Rebase. Это не вредит совместимости между репозиториями.
  • Теперь, когда вы здесь, вы можете:
    • Удалите там, где началась ваша закладка (это, вероятно, решит вашу проблему)
    • Для облегчения визуализации, возможно, вы могли бы перебазировать ваши изменения спереди, а затем удалить их. Я только что упомянул rebase, потому что это может быть чем-то полезным для вас в другой раз.

Кроме того, в git у вас могут быть «частные локальные ветви», потому что вы должны явно их выдвигать, а потом можете их удалить. В Mercurial вы продвигаете все, что у вас есть , однако, если вы хотите избежать этого, вы можете использовать функцию фаз и пометить ряд ревизий как секретные . Секретные изменения не будут выдвинуты.

Наконец, вы не делаете ничего плохого , просто имейте в виду, что это просто разные инструменты, построенные с немного отличающимся мышлением, которые в значительной степени сводятся к следующему: изменение истории (git) или не изменение истории (hg). В Mercurial труднее выстрелить себе в ногу, изменяя историю (особенно с Фазами), и поэтому некоторым это нравится лучше, чем git .


Нет никакого способа гарантировать, что все децентрализованные копии наборов изменений, которые записывают именованную ветвь, были удалены после выполнения hg strip. Я полагаю, что то же самое можно сказать и о децентрализованных копиях имен веток Git, за исключением того различия, что именованные ветви имеют глобальное пространство имен, а имена ветвей Git - нет. И несколько голов существуют из-за ветвей имен. Это своего рода заразительная ошибка проектирования для децентрализованного VCS.
Шелби Мур III

1

Я считаю, что с Mercurial легче всего не беспокоиться о ветвях. Я просто нахожу, где в истории я хочу редактировать и создавать коммиты по мере необходимости (анонимные ветки). Иногда закладки могут быть полезны, если мне приходится прыгать между головами в разных контекстах, но чаще всего я не беспокоюсь о них. Именованные ветви подходят для долгоживущих ветвей (ветки исправления ошибок, ветки проекта), но для исправлений с 1 или 2 фиксациями они не являются подходящим инструментом для работы.

Хитрость с анонимными ветвями состоит в том, чтобы установить их фазу на «секретный», если вы не хотите их выдвигать, т.е. если вы хотите, чтобы они были локальными. Если вы действительно хотите , чтобы подтолкнуть их, но вы не хотите больше никаких фиксаций на их основе, вы просто совершить «--close-ветвь» на них сверху , который не означает , что они больше не появляются в списке "головок и ртутный перестанет жаловаться на несколько голов в этой ветви.


-1

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

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