Почему Меркуриал считается более простым, чем Гит?

Если посмотреть на сравнения, мне кажется, что между их наборами функций может быть отображение 1: 1. Тем не менее, часто цитируется утверждение, что «Mercurial легче». В чем заключается основа этого заявления? (если есть)

204 голоса | спросил 2 revs, 2 users 67%
Tamás Szelei
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

9 ответов


241

Пример: предположим, что вы хотите изменить имя пользователя во всех своих предыдущих фиксациях. Мне нужно было сделать это несколько раз по разным причинам.

Версия Git

git filter-branch --commit-filter '
        если ["$ GIT_COMMITTER_NAME" = "<Old Name>" ];
        тогда
                GIT_COMMITTER_NAME = "<Новое имя>";
                GIT_AUTHOR_NAME = "<Новое имя>";
                GIT_COMMITTER_EMAIL = "<New Email>";
                GIT_AUTHOR_EMAIL = "<New Email>";
                git commit-tree "$ @";
        еще
                git commit-tree "$ @";
        fi 'HEAD

Меркуриальная версия:

archive.convert.list файл:

& л; Старое_имя > = & л; новое_имя >

Командная строка:

hg convert --authors authors.convert.list ИСТОЧНИК DEST

Теперь, какой из них проще использовать?


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

Для меня это удобство. Git - это очень Linux, ориентированный на Linux-процесс. Это означает, что вы используете командную строку, man-страницы и вычисляете ее сами. У этого был очень плохой графический интерфейс (примечание: я основываю это на msysGit примерно год назад), который, казалось, просто мешал мне. Я едва мог его использовать

Командная строка была хуже. Будучи ориентированной на Linux программой, в Windows это было очень сложно использовать. Вместо собственного порта они просто завернули git с помощью MinGW (Think cygwin), что сделало работу с ним намного сложнее. MinGW - это не командная строка Windows, а просто разные. Это безумие, что это единственный способ работать с Git. Даже в Linux казалось, что единственный способ - работать с прямой командной строкой. Такие проекты, как RabbitVCS, помогли некоторым, но не очень мощным.

Подход, ориентированный на командную строку и являющийся программой linux, означал, что почти все руководства по руководству, справочная документация и вопросы форума /QA основываются на запущенных чудовищных командах, как описано выше. Основные команды SCM (commit, pull, push) не так сложны, но все больше и сложнее растет экспоненциально.

Я также ненавижу одно место, в котором много пользователей OSS git, похоже, висят: Github. Когда вы впервые переходите на страницу github, это захлопывает вас всем, что вы можете сделать. Для меня проект git page выглядит хаотичным, страшным и чрезмерно мощным. Даже объяснение того, что представляет собой проект, подталкивается вниз. Github действительно болит людей, у которых нет полноценного веб-сайта, уже настроенного. Трекер его проблем также ужасен и запутан. Перегрузка функции.

Пользователи Git также казались очень культовыми. Похоже, что пользователи Git всегда начинают «священные войны», над которыми лучше всего работает DVCS, что заставляет пользователей Mercurial защищаться. Сайты, подобные http://whygitisbetterthanx.com/, демонстрируют высокомерие и почти менталитет «Использовать мое программное обеспечение или умереть». Много раз я побывал в разных местах помощи только для того, чтобы быть пылким, не зная X, используя X заранее, используя Windows и т. Д. Это безумие.


Mercurial, с другой стороны, похоже, идет к более доброжелательному подходу. Их собственная домашняя страница кажется гораздо более дружественной для новых пользователей, чем Git's . В простом поиске Google 5-й результат - TortoiseHg, очень приятный графический интерфейс для Mercurial. Весь их подход, по-видимому, сначала является простотой, потом мощью.

С Mercurial у меня нет SSH ерунды (SSH - ад в Windows), у меня нет глупо сложных команд, у меня нет поклонников, у меня нет сумасшествия. Mercurial просто работает.

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

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

Mercurial также работает в первый раз с небольшой настройкой. На ЛЮБОЙ ОС я могу просто установить TortoiseHg и получить все функции, которые я хочу (в основном, контекстные меню) без необходимости искать других Guis. Также отсутствует настройка SSH (половина гидов там говорит, чтобы использовать Putty, Plink и Pagent, в то время как другая половина говорит использовать ssh-keygen). Для новых пользователей TortoiseHg занимает минуты, чтобы настроить, в то время как Git занимает 30 минут до часа с большим количеством поисковых запросов.

Наконец, у вас есть онлайн-репозитории. Эквивалент Githubs - это BitBucket, у которого есть некоторые из проблем, которые я изложил выше. Однако есть и Google Code. Когда я перехожу к проект Google Code , я не получаю перегрузку функции, я получаю приятный чистый интерфейс. Google Code - это скорее комбо онлайн-репо /сайт, который действительно помогает проектам OSS, у которых нет существующей настройки сайта. Я бы чувствовал себя очень комфортно с помощью Google Code в качестве своего веб-сайта проектов в течение некоторого времени, создавая веб-сайт, когда это абсолютно необходимо. Его трекер-пробник также является мощным, прекрасно сочетается между почти бесполезным Tracker от Github и Чудовище Bugzilla .

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

ответил user62575 20 MarpmMon, 20 Mar 2017 13:31:06 +03002017-03-20T13:31:06+03:0001 2017, 13:31:06
80

Git против Mercurial

  

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

Концепции Git

  

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

ответил user62575 20 MarpmMon, 20 Mar 2017 13:31:06 +03002017-03-20T13:31:06+03:0001 2017, 13:31:06
47

Контекст: я ежедневно использую как Mercurial (для работы), так и Git (для сторонних проектов и с открытым исходным кодом). В первую очередь я использую текстовые инструменты для обоих (не для IDE), и я нахожусь на Mac.

В целом, я считаю, что Mercurial легче работать. Несколько вещей, которые я нахожу, упрощают Mercurial:

  1. Недостаток индекса. Индекс - это мощный инструмент, позволяющий использовать многие функции Git, но это также дополнительный слой, который добавляет шаг во многие вещи, которые я делаю регулярно. Рабочий процесс Mercurial более похож на нечто вроде svn.
  2. Номера ревизий вместо shas. Это небольшая вещь, которую я нахожу, делает работу с ежедневными командами намного проще в Mercurial. Легче нажать несколько ревизий в голове во время переустановки, слияния и т. Д. При написании команды, чем сделать то же самое с укороченными шарами.
  3. Филиалы. Подход Git к филиалам посредством котировок именования является мощным и существенно отличным от других систем управления версиями. Это упрощает некоторые вещи. Я нахожу, что подход Mercurial соответствует svn, думающему немного лучше, и упрощает визуальное понимание истории филиалов. Это может быть предпочтительным.
ответил user62575 20 MarpmMon, 20 Mar 2017 13:31:06 +03002017-03-20T13:31:06+03:0001 2017, 13:31:06
29

Это очень субъективно и зависит от одного человека к другому, но да, я бы пошёл к кому-то совершенно новому для VCS или кому-то, кто пришел из одной из «VCS» старой школы, Mercurial будет казаться легче.

Например, добавление файлов, отсутствие индекса в Hg, легкость вернуться к некоторой старой ревизии и ветвлению оттуда (просто обновить и зафиксировать) как некоторые из наиболее «очевидных» примеров. Теперь большинство функций одной системы можно эмулировать в другой и наоборот, но это требует некоторых знаний в Git, в то время как в Mercurial значения по умолчанию (если вы позволите мне называть их) скорее «удобны для пользователя». Эти мелочи - переключатель здесь и там, неочевидное поведение в одной команде и так далее ... эти вещи складываются, и, в конце концов, одна система кажется более простой в использовании, чем другая.

Просто, чтобы закончить ответ; Я использую git, но, рекомендуя VCS для кого-то, кто «новый для них», я почти всегда рекомендую Mercurial. Я помню, когда он впервые попал мне в руки, это было очень интуитивно. По моему опыту, Mercurial производит меньше wtf /min, чем Git.

ответил user62575 20 MarpmMon, 20 Mar 2017 13:31:06 +03002017-03-20T13:31:06+03:0001 2017, 13:31:06
17

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

ответил user62575 20 MarpmMon, 20 Mar 2017 13:31:06 +03002017-03-20T13:31:06+03:0001 2017, 13:31:06
9

Восприятия могут меняться со временем. Mercurial очень хорошо спроектирован, а также Git. Меркуриал, кажется, легче учиться (по крайней мере, это было для меня), и были трудности, с которыми я столкнулся в Git, что у меня нет параллели в Mercurial. Я пытался научиться Python и Ruby, и стал дальше, быстрее с Python. Это не значит, что Python всегда и везде лучше, чем Ruby, или даже, что это лучше для меня. Это то, что я узнал и застрял. Программисты часто делают священные войны личными предпочтениями. Другие люди тоже это делают.

Я - меркуриальный пользователь, который пытается сохранить открытый взгляд на Гит, и я свободно признаю, что он не «стал моей новой любимой вещью» в той же степени, что и Mercurial. Я думаю, что Git действительно очень хорош, хотя.

Пример счетчика для сложности GIT /mercurial: поддержка Nice GIT встроена в XCode на Mac. Менее проста в использовании XCode с Mercurial, чем GIT.

Мой опыт работы с GIT до сих пор заключался в том, что я запутался и потерялся, и вам нужно больше советоваться с документацией при использовании. Я считаю, что было написано много документации, но ничего, что позволило мне «заманить» ее. Во-вторых, я могу легко модифицировать и расширять Mercurial в Python, и, поскольку я умею разбираться в Python, и, поскольку кто-то действительно может быстро изучить python, это кажется мне преимуществом. Я также знаю C и записываю расширения Python в C, поэтому, полагаю, однажды, если бы мне это было нужно, я мог бы легко написать расширение Git в C.

Простота использования - это не то, что легко определить количественно. Он есть, и я не думаю, что это полностью субъективно, но у нас нет хороших объективных методов измерения. Какими будут единицы для удобства использования? Milli-плеер?

Я не настолько пристрастен, чтобы быть на 100% про-меркуриальным и 100% анти-git. Теперь я более комфортно отношусь к Mercurial, в Windows и Linux, и когда я начинаю делать больше работы с Mac, я ожидаю, что я попытаюсь придерживаться XCode + GIT.

Обновление 2013: . Теперь я использовал Mercurial AND GIT достаточно долго, чтобы найти некоторые функции, которые, как мне бы хотелось, у Git, такие как этот вопрос о стратегиях слияния. Действительно, Git поражает, если трудно учиться, а иногда и безумно сложно.

ответил user62575 20 MarpmMon, 20 Mar 2017 13:31:06 +03002017-03-20T13:31:06+03:0001 2017, 13:31:06
7

Есть несколько вещей, которые ИМО, вероятно, отключат новых пользователей от Git:

  1. Культура Git больше ориентирована на командную строку. Хотя оба инструмента имеют тенденцию слишком сильно фокусироваться на командной строке (как я уже говорил несколько раз, команды командной строки могут быть мощными и более свободными, но они не являются хорошей маркетинговой стратегией ), это гораздо больше касается Git. В то время как Mercurial имеет де-факто стандартный инструмент GUI в TortoiseHg, который даже является вариантом загрузки по умолчанию для пользователей Windows на домашней странице Mercurial, у Git есть несколько конкурирующих интерфейсов GUI (TortoiseGit, Git Extensions, gitk и т. Д.), Которые недостаточно рекламируются на веб-сайте Git, и в любом случае все они прекрасно видны. (Черный текст на красных ярлыках? C'mon, TortoiseGit, вы можете сделать это лучше!) В сообществе Git также есть более распространенное мнение о том, что люди, которые используют инструменты GUI, не являются надлежащими разработчиками программного обеспечения.

  2. Git имеет несколько стандартных настроек по умолчанию, которые имеют прекрасный смысл для продвинутых пользователей, но, вероятно, будут удивлять, если не запугать новых пользователей. Например, гораздо более агрессивно относится к автоматизации задач, таких как слияние (например, git pull автоматически объединяется и фиксируется там, где это возможно). Существует случай для полностью автоматизированных слияний , но большинство неопытных пользователей боятся слияния и должны получить возможность завоевать доверие к своим инструментам, прежде чем развязать свою полную силу на их исходный код.

  3. Документация и неотъемлемая сложность:

    $ hg help log | wc -l
    64
    $ git help log | wc -l
    912
    
ответил user62575 20 MarpmMon, 20 Mar 2017 13:31:06 +03002017-03-20T13:31:06+03:0001 2017, 13:31:06
3

Одна вещь, о которой я могу думать, -

git add.
git commit -am "message"

против.

hg ci -Am "сообщение"

git commit -a не добавляет вновь созданные файлы, hg ci -A делает, что означает, что что-то, что требует две команды с git, может быть выполнено с помощью одного команду в Mercurial. Опять же, «меньше набрав» не обязательно означает «более удобный».

ответил user62575 20 MarpmMon, 20 Mar 2017 13:31:06 +03002017-03-20T13:31:06+03:0001 2017, 13:31:06
3

Потому что это.

Гит раскрывает гораздо больше своих мужеств, чем меркурий. Вы можете с радостью использовать mercurial в течение нескольких минут после его сбора, но я нахожу git еще очень тяжело схватиться после нескольких месяцев борьбы с ним (я сделал очень мало за последние пару месяцев, кроме как попытаться изучить git ). Я использую как из командной строки, так и в основном в Linux, поэтому это не просто отвращение к интерфейсу командной строки.

Один простой пример - относительно небольшое количество флагов и аргументов командной строки, необходимых для меркуриона по сравнению с git. Промежуточная область и поведение команды add в git также добавляет больше сложности, чем это необходимо. Трио сброса, проверки и возврата и их множественных перестановок добавляет огромную сложность, что совершенно не нужно, когда вы являетесь свидетелем прямого характера возврата и обновления на mercurial.

Я согласен с вышеуказанным комментарием и о Hginit , это определенно сделало mercurial намного легче понять. Хорошо написано и очень легко понять. Ни одна из документации, написанной для git, не подходит. Я, например, нахожу большую часть того, что написано Скоттом Чаконе (который единолично написал большую часть документации /книг о git), особенно запутанной.

ответил user62575 20 MarpmMon, 20 Mar 2017 13:31:06 +03002017-03-20T13:31:06+03:0001 2017, 13:31:06

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132