Почему Mercurial проще, чем Git?

204

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

Tamás Szelei
источник
21
Странно, я никогда не слышал, что Mercurial было проще. Я нашел больше документации для Git (возможно, восприятие), поэтому я узнал это.
Nic
16
Потому что это сделал Линус?
Работа
124
Вернувшись на территорию священной войны, я обнаружил, что Mercurial проще в использовании, чем Git, потому что, как пользователь Windows, я чувствовал себя приветствуемым Mercurial и относился к Git как к уроду и неудачнику. Я знаю, что я антропоморфизирующее программное обеспечение, и я знаю, что оба они прекрасно подходят для использования под Windows, но это впечатление, производимое двумя из них.
Carson63000
24
hginit.com
Svish
11
Интересно, сколько людей будет использовать Git, если Github не существует или у него не так много громких проектов?
Крис С

Ответы:

240

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

Git Version

git filter-branch --commit-filter '
        if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
        then
                GIT_COMMITTER_NAME="<New Name>";
                GIT_AUTHOR_NAME="<New Name>";
                GIT_COMMITTER_EMAIL="<New Email>";
                GIT_AUTHOR_EMAIL="<New Email>";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

Mercurial версия:

Файл авторы.convert.list:

<oldname>=<newname>

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

hg convert --authors authors.convert.list SOURCE DEST

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


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

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

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

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

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

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


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

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

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

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

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

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

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

TheLQ
источник
6
Комментаторы: комментарии предназначены для уточнения, а не для расширенного обсуждения. Если у вас есть решение, оставьте ответ. Если ваше решение уже опубликовано, пожалуйста, подпишите его. Если вы хотите обсудить этот вопрос с другими, используйте чат . Смотрите FAQ для получения дополнительной информации.
1
IntelliJ IDEA и Xcode 4 имеют прекрасную интеграцию с Git на их соответствующих платформах, и для повседневных задач вам никогда не придется использовать командную строку.
4
Я хотел бы добавить, что tortoiseGIT намного лучше, когда вы хотите использовать GIT на Windows. Вам все еще приходится иметь дело с ключами SSL, и процесс установки не является гладким, но когда это сделано, это работает легко.
Арх
2
Расширения Git Лично мне гораздо проще ориентироваться и работать с TortoiseHG в Windows, и я когда-либо использовал только 1 командную строку с git.
KallDrexx
1
Я немного сбит с толку этой строкой: «MinGW - это не командная строка Windows, а просто действует по-другому. Это безумие, что это единственный способ работать с Git». Я использую установку msysgit и опцию 2 для запуска из командной строки Windows. Работает нормально. Есть несколько вещей, которые не работают (например, знак вставки, символ продолжения строки в DOS), но есть альтернативы тем (например, тильда), которые работают нормально. Я не энтузиаст командной строки (или, по крайней мере, я не был до того, как начал изучать Git), но использовать Git с командной строкой действительно легко. Я что-то пропустил?
Kyralessa
80

Git против Mercurial

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

Git Concepts

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

Циклоп
источник
73
Так что Mercurial скрывает только расширенную функциональность, а GIT скрывает всю функциональность ... ;-)
благоговение
4
Git имеет больше власти. Например, нет эквивалента HEAD GIT ~ 1 . У Mercurial есть p (x), который распространяется через ветви, насколько бесполезно. Там нет стадии в ртути. Все ветви должны быть нажаты при нажатии. Mercurial не так гибок даже со всеми плагинами, такими как histedit, shelf и rebase. Командная строка Git также лучше, она дает пользователю подсказки, а Mercurials - нет. Я вынужден использовать эту слегка поврежденную систему DVCS на работе, и я попал в ситуации, когда у Mercurial нет возможности делать то, что я хочу.
Keyo
22
@Keyo: Mercurial ~, смотрите revsets . Он не имеет промежуточной области, но вы можете эмулировать его с помощью MQ, который намного мощнее. Научитесь использовать инструмент, а не придерживаться того, что вы знаете из git, это окупится.
Идан К
22
@Keyo: Вам не нужно нажимать все ветви с Mercurial, когда вы нажимаете. Вы можете нажать определенную ветку ( hg push --branch BRANCH) или до определенной ревизии ( hg push --rev REV). Пожалуйста, смотрите hg help pushбольше вариантов.
Регент
1
К вашему сведению, можно получить значительное подмножество области подготовки, используя расширение записи . OTOH, я думаю, что расширение полки (смоделированное по команде «shelve» от Baazar и близкое к «git stash») служит гораздо лучше для большинства целей использования области подготовки.
Brandizzi
47

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

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

  1. Отсутствие индекса. Индекс - это мощный инструмент, позволяющий использовать многие функции Git, но это также дополнительный слой, который добавляет шаг ко многим вещам, которые я регулярно делаю. Рабочий процесс Mercurial больше похож на svn.
  2. Номера ревизий вместо шас. Это небольшая вещь, которая, как мне кажется, значительно облегчает работу с ежедневными командами в Mercurial. Проще вставить несколько номеров ревизий в вашу голову во время перебазирования, слияния и т. Д. При написании команды, чем делать то же самое даже с укороченными шасами.
  3. Ветви. Подход Git к ветвям с помощью фиксации имен мощен и существенно отличается от других систем контроля версий. Это делает определенные вещи намного проще. Я считаю, что подход Mercurial соответствует SVN мышления немного лучше и облегчает визуальное понимание истории отрасли. Это может быть просто предпочтением.
Алекс Миллер
источник
6
+1 за упоминание индекса; Я думаю, что индекс и его взаимодействие - это то, что делает git более трудным для изучения, чем mercurial.
Шон Макмиллан
18
hgЭквивалент gitветвей на самом деле называется bookmarks. Насколько я знаю, hgфилиалы не имеют эквивалента в git.
Хэнк Гей
6
Я в такой же ситуации, с ртутью на работе и мерзавцем дома. Ртутное разветвление довольно раздражает меня, я люблю иметь частные ветки и вставлять их, когда захочу. Mercurial заставляет меня использовать полки или дополнительные репозитории. Номера ревизий глупы, дай мне хэш. Сцена отличная в Git, я скучаю по этому. Мне действительно не хватает силы мерзавца. Я сделал несколько вещей с некоторыми плагинами, но ветвление действительно раздражает меня.
Кейо
6
@ Keyo - по моему опыту, gitветвление является подмножеством hgветвления. В hgвы можете иметь оба названных и неназванных (топологические) ветви, и даже может управлять неназванные ветви таким же образом , как с gitпомощью закладок. Я никогда не видел точку в области постановки. Я бы предпочел отложить нежелательные изменения, а затем убедиться, что мой код компилируется и завершает мои тесты перед его фиксацией. Я могу тогда отложить полки и продолжить. Кроме того, Чарльз Бэйли «Массирующие глыбы» ( стр. 90
Марк Бут
7
@Keyo: В Mercurial частные ветки называются «закладками»: обновлять корневую ревизию hg bookmark keyo-stuff, делать что-то hg commit, а потом, в конце концов hg push -B keyo-stuff. Если вам не нравятся номера ревизий, не используйте их; Я думаю, что Mercurial примет хэш везде, где он примет номер ревизии. Я должен сказать, что ваши комментарии, избивающие Mercurial из-за отсутствия функций, которые он на самом деле выглядел как невежественные и немного агрессивные; Вы не делаете много хорошего для стереотипа пользователей Git!
Том Андерсон
29

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

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

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

ладья
источник
+1 для «меньше wtf / минуту» -1 для «это очень субъективно». Это не очень субъективно ... Я не знаю, почему люди все еще считают различия в интерфейсе субъективными. Если я возьму mercurial и md5-хэш с его командами, вы не станете утверждать, что некоторые люди могут найти md5-хэш более интуитивно понятным, чем оригинал, не так ли? (Надеюсь нет). То же самое относится и к Git. Git проще, чем Mercurial, если ваш опыт работы с Git значительно более существенен, чем Mercurial.
weberc2
17

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

pdr
источник
7
Нет. Слишком много шагов рабочего процесса, чтобы вы могли назвать его просто «другим синтаксисом». Вы должны понимать основную модель, которой вы управляете, и все состояние индекса git, чтобы использовать Git. Сказать, что SQL и Pascal - это два разных синтаксиса для одной и той же вещи, было бы одинаково неправильно. Git - это система управления версиями файловой системы с функциями DVCS. Mercurial - это DVCS, которая не выполняет все операции управления версиями файловой системы, выполняемые GIT, а только ту подмножество, которое требуется всем пользователям DVCS.
Уоррен П
9

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

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

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

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

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

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

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

Уоррен П
источник
7

Есть несколько вещей, которые IMO могут оттолкнуть новых пользователей от Git:

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

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

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

    $ hg help log | wc -l
    64
    $ git help log | wc -l
    912
    
jammycakes
источник
3
На самом деле, я предпочитаю помощь длиной 912 строк, а помощь - 64.
Dysaster
10
На самом деле, я предпочитаю пользовательский интерфейс, который настолько интуитивно понятен и прост, что вам не нужна помощь.
jammycakes
2
Я хочу и графический интерфейс, и помощь. :) То, что мне кажется интуитивно понятным, это беспорядок для кого-то еще.
Dysaster
1
Конечно, но когда нужна помощь, за ней должно быть легко следовать.
jammycakes
3
Я подумал о новой аналогии; Git похож на C ++ (простите, Линус!), А Mercurial - на Паскаль. То, что подразумевается и может быть сделано только одним способом в Pascal (или Mercurial), может быть сделано явно, девятнадцатью различными способами в C ++ (и Git). Некоторые люди предпочитают электроинструменты с большим количеством кнопок и рычагов, и это Git.
Уоррен П
3

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

git add .
git commit -am "message"

против

hg ci -Am "message"

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

Чжэхао Мао
источник
11
Я часто нахожу, что в моем рабочем процессе автоматическое добавление новых файлов на самом деле нежелательно. Я предпочел, как git commit -aработает просто потому, что это облегчает контроль того, что добавляется и не добавляется для данного коммита. (На самом деле для меня нет ничего необычного в том, чтобы указывать индивидуальные пути для каждого, svn ciчтобы избежать добавления не связанных материалов в коммит.)
greyfade
3
Справедливо, но я считаю, что hg ciбез -Aфлага это эквивалентно git commit -a. Я использовал git намного больше, чем hg, поэтому я не уверен на 100%.
Чжэхао Мао
Я проверил, hg ci== git commit -a.
Чжехао Мао
но если вы укажете определенные файлы с помощью hg commit, вы можете избежать добавления тех, которые вам не нужны. В редких случаях, когда я хочу этот контроль, я считаю, что это работает хорошо.
Алекс Миллер
1
зачем тебе "мерзавец добавить". а потом "git commit -am"? Не все ли уже будет добавлено в индекс?
Якобангел
3

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

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

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

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

оборота хазиз
источник