Comments 41
Из крупных проектов, продолжающих использовать Mercurial, можно выделить OpenOffice.org, OpenSolaris, Nginx
Грустно, что mercurial проиграл. Мне он нравился значительно больше git, но, увы, для взаимодействия с другими лучше пользоваться общепринятым инструментом, чем экзотическим.
Для огромных проектов с субмодулями git лучше подходит. а за огромными и прочие подтянулись.
Возможно, но мне кажется, в первую очередь повлияло, что гит лучше подходит для Линуса. Роль личности в истории :-)
Если я ничего не путаю, фэйсбук топит за меркуриал как раз потому что гипотетически гит будет тормозить на их огромном гипотетическом монорепе. И они как раз допиливали архитектуру меркуриал с прицелом на огромные кодовые базы
https://habr.com/ru/articles/798881/
Компания Facebook* выбрала Mercurial не потому, что он был более производителен, чем Git. Она выбрала его, потому что мейнтейнеры и кодовая база были более открыты к сотрудничеству. Инженеры Facebook* лично встретились с мейнтейнерами Mercurial, и им понравилась идея партнёрства
Microsoft пошла немного другим путём и допиливала git под свои размеры
Аналогично. Полноценные ветки + изначально нормальный GUI. Но, ещё лет несколько назад перебрался полностью на git, ибо, да, mercurial превратился в экзотику.
Грустно, что проиграл svn, хотя он продолжает быть вторым. А в hg, кажется, была постоянная проблема с юникодными именами файлов? Конечно, использование non-ascii символов в именах вредно для здоровья, но не все такие пуристы в этом вопросе.
А мне не особо жалко. Помню даже, что во времена SVN бытовало мнение что-де контроль версий нужен исключительно для командной работы, а для pet project достаточно и archiveYYMMDD.zip. И это, имхо, неспроста.
в hg, кажется, была постоянная проблема с юникодными именами файлов?
Причем ее кажется так и не починили. В 21 веке как то странно.
А ещё в hg каждая следующая версия несовместима с предыдущей. Старый клиент новый репозиторий не читает.
А Меркуриал в какой системе контроля версий мейнтейнится?
Я немного не понял. Пишут, что перешли на Git и Github, но репозиторий создан более 20 лет назад? https://github.com/nginx/nginx/commits/master/?after=00637cce366f17b78fe1ed5c1ef0e534143045f6+8270
Есть hg-fast-export.
Коммиту в гите можно поставить любую дату. Как думаете работают тулзы для написания текстов в диаграмме Contributions в гитхабе?
Там у nginx уже давно было сделано зеркало. Но репозиторий работал именно как реплика, а теперь реплика стала мастером.... ну или как там теперь надо полит-корректно назвать....
А мне вот прямо больно от того что git и github все больше становятся мейнстримом без каких либо альтернатив. Уже сейчас становится заметно как продукты постепенно начинают стогнировать на фоне отсутствия конкуренции. Может это больше к github относится
Ого, аж временами FIDO и BBS повеяло.
Так сложилась судьба, что руки попробовать Mercurial у меня так и не дошли.
Может мне тут кто-нибудь объяснить о чем тут плач Ярославны и чем всем не угодил Git?
чем всем не угодил Git?
git сложное.
о чем тут плач Ярославны
Птичку жалко. (ц)
Ну так то mercurial никуда не пропал В дистрибутивах linux он есть, можно установить и пользоваться.
git сложное
А можно мне объяснить в чём именно сложности с Git? В простых сценариях гит прост как две копейки, в сложных - сложность вытекает не из git-а, а из самой сложности проблемы совместной разработки и версионирования кода.
Если сильно не копаться в деталях внутреннего устройства, то я могу на кубиках объяснить git любому человеку минут за 30.
Бранчи там организованы сложно. Если сравнивать с hg.
Если хочется удалить 1 ошибочный комит, в hg это просто strip. В git - целое упражнение из лечебной физкультуры.
Просто посмотреть, есть ли новые комитеты на сервере, но не скачивать? В mercurial - hg in В git - не нашел как
Просто скачать новые комитеты, я позже разберусь, что делать со своими? hg pull. В git - хозяин, я все смержииль, подтверждай давай.
Mercurial проще в работе. git более навороченный, бесспорно.
git reset HEAD~1. Где тут физкультура? Ну, если вы уже залили этот комитет, то ССЗБ, и все сложности начинаются именно из-за механизма совместной работы с кодом, git тут не причём. Если на других плевать, то git push --force решит ваши проблемы.
git fetch? Ну, да, он скачает новые космитв, а не просто посмотрит, но зачем нужно "просто посмотреть" - загадка.
git fetch всё также решит ваши проблемы. Потому что git pull он просто делает fetch + merge/rebase, но если вы хотите вручную разгребать - просто юзайте fetch
git reset HEAD~1
--hard вроде ещё нужно. И вот этот стиль HEAD~1.. не могу никак запомнить;) Ну то есть мы не убираем комит, а откатывается на предыдущий. И он там где-то в потрохах остаётся. А в hg урезать значит урезать ;)
не могу никак запомнить
Читайте '~' как знак минус и всё встаёт на свои места. "Вернуться назад от текущего места на один шаг". Или на 2 шага. Или на три) В зависимости от цифры.
Впрочем в git можно добавить alias-ы для команд, так что можете специально для себя сделать команду strip и просто писать git strip.
Касаемо --hard, зависит от того, хотите ли вы удалить коммит или удалить и код, и коммит) Если просто удалить коммит, то надо без hard) Задача была "удалить ошибочный коммит" - я её и решил)
И снова - вся сложность вытекла из сложности процесса версионирования, а не сложности команд)
Бранчи там организованы сложно. Если сравнивать с hg.
Бранчи в Hg организованы сложно. Если сравнивать с Git.
Сами авторы Hg пишут в документации, что «The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial.» - прямая цитата из родной вики. В Hg понятие ветки это смешение нескольких разнородных сущностей в одну не сильно приятную (именно из-за смешения) кашу:
1. «Голова» процесса развития, которых может быть несколько в пределах одной рабочей копии или «ветки» в другом понимании. При операциях push, pull передаются все эти головы. В некоторых местах это называется напрямую словом head.
2. Некий установленный локальным режимом тег под названием «branch», который приклеивается к каждому новому changesetʼу, и больше ничего не делает. Именно его чаще всего называют «веткой».
3. Полный пучок п.1, между которыми тоже можно переключаться (множественные головы, которые используются ничтожной частью пользователей, но которые всем надо учитывать).
4. Bookmarks, которые тоже ветки, аналогично Git, но не получили такое имя из-за намеренного отказа разработчиков.
После этого в Git всё тривиально. А основную обиду большинства сторонников Mercurial получает то, что нет автомата, который пишет название локальной ветки-2 при коммите в атрибуты коммита. В Git это решается явной записью в сообщение коммита, причём чаще всего не в виде ветки, а в виде тикета, под который идёт разработка.
На остальное уже ответили в ветке обсуждения.
Mercurial успешнее, чем Git, изображает то, что реально нужно ≈90 процентам пользователей - использовать распределённую VCS как централизованную, при этом получая некоторые фишки распределённости в виде временного (долго всё равно не нужно) сохранения коммита (changeset, в терминах Mercurial) у локального пользователя. Полные фишки Git всё равно мало кто использует, слово index уже пугает значительную часть пользователей, а rebase вообще аватарой аццкого сотоны в пределах рабочей копии. В эту сторону работают такие фишки, как последовательная нумерация ченжсетов, вписывание имени текущей ветки в метаданные коммита, и тот же отказ от индекса, который требует других, сильно более топорных инструментов, но при этом визуально более наглядных.
В чём-то я их понимаю - я тоже раз пять делал - "git diff" - "что??? где мои правки???" - "git status" - "ааа блин, они в индексе, смотрим git dc (алиас у меня такой)", и пока не научился делать какой-нибудь "git rebase --abort" и вообще внимательно читать вывод git status, пару раз таки делал как на xkcd нарисовано - убить рабочую копию, стянуть с нуля и сделать заново. Сейчас уже не делаю, но это потому, что я понимал, что если ничего не получается, надо прочесть внимательно ;)
Нуну, ждём, не вспомнит ли мс, владелец гитхаба, что у нжинкса русские корни.
Разработка Nginx перешла с Mercurial на Git и GitHub