LINUX.ORG.RU
ФорумTalks

Пал один из последних оплотов Mercurial (Hg)

 , , , ,


2

4

!Ъ: Разработка OpenJDK переведена на Git и GitHub

Кто там остался из релевантных на ртути? Mozilla Firefox и SDL2?

– SDL2 (update 10-Feb-2021):

Главный разработчик SDL2 заявил, что они переезжают с Mercurial (Hg) и Bugzilla на Git и GitHub.

Получается, остались лишь Firefox да Nginx?

★★★★★

Внимание разрабов переключилось с альтернативных VCS на альтернативные морды к гит (GitHub и аналоги, tig и аналоги)

Crocodoom ★★★★ ()
Ответ на: комментарий от WitcherGeralt

Не знал что они на ртути, думал Git во все поля.

EXL ★★★★★ ()

Заколачивайте надежнее, чтобы оно не вылезло.

Аве гит! Так победим.

wandrien ()

Аминь. Собаке - собачья смерть.

slovazap ★★★★★ ()

!Ъ: Разработка OpenJDK переведена на Git и GitHub

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

byko3y ★★ ()
Ответ на: комментарий от cvs-255

а какие преимущества у mercurial?

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

А интерфейс у гита настолько убогий и опасный в применении, что ныне возникла профессия «админ репы гита». По абсурду это что-то уровня «менеджер поддержки блокнота» или «админ калькулятора» — инструмент, который должен был быть незаметным и просто выполнять свои функции, стал теперь фокусом внимания.

byko3y ★★ ()
Ответ на: комментарий от targitaj

Ну пусть поставят себе белый фон и черные буквы. Будет как в книгах

Книжки то они умеют читать? Там сплошные буквы

cvs-255 ★★★★★ ()
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от cvs-255

Быть в состоянии произнести вслух звуки фонетического письма не означает уметь читать.

targitaj ★★★★★ ()
Ответ на: комментарий от byko3y

потому что ретрограды у руля разработки гита принципиально отказываются делать интерфейсы, отличные от текста аля «юникс-вей», через которые работают все тулзы под гит

Есть же https://libgit2.org/

Её юзает Microsoft в своих IDE.

EXL ★★★★★ ()
Ответ на: комментарий от cvs-255

Мне как-то говорили, что он хранит в коммите название ветки. Не знаю почему, но человек рассказавший об этом, считал,что это «очень важно!». Открываю одну из его реп и вижу 2 ветки с именем default (hg позволяет так делать).

А так мне всё равно чем из них пользоваться.

grem ★★★★★ ()
Ответ на: комментарий от cvs-255

А что не так с интерфейсом гита? Какие команды непонятны?

Что угодно кроме сверх «скачать репу» и «запушить правки без конфликтов», например:
https://git-scm.com/docs/git-reset

Хотя там полный унос мозгов на любой странице из официальных доков. Я понимаю, что в 99% случаев вопросы решаются путем «загугли проблему, скопируй решение. Если не помогло — повтори».

https://xkcd.com/1597/

Но факт остается фактом: командная строка у гита запутанная, параметры неочевидны, а официальная документация никак не помогает, если ты не являешься экспертом по калькулятору git.

byko3y ★★ ()
Ответ на: комментарий от grem

mercurial - консольная утилита

И это неправильный ответ. Консольная тулза представляет собой малую долю системы.

byko3y ★★ ()
Ответ на: комментарий от invy

Git gui и gitk

Это мусор. Всерьез их можно воспринимать только если больше ничего в жизни не видел.

В меркуриале все сложнее чем коммит и пуш делается из такими же заклинаниями

Во-первых, командная строка mercurial проще и понятнее, хоят действия примерно те же нужно делать, да. Во-вторых, командная строка является далеко не единственным интерфейсом.

byko3y ★★ ()
Ответ на: комментарий от grem

То бишь у mercurial нету какой-нибудь там libhg.so, реализующий нормальные интерфейсы взаимодействия вместо убогих «вызываем консольную утилиту, парсим выхлоп»?

meh

EXL ★★★★★ ()
Ответ на: комментарий от EXL

Есть, как минимум, command server (A server that allows communication with Mercurial’s API over a pipe), который позволяет выпускать внешние тулзы под любой лицензией. Может и в другом виде есть доступ к API для внешних библиотек.

Но внешние тулзы - это внешние тулзы, а не сам mercurial или git. А упомянутый выше libgit, почему-то так и не сподвиг никого написать лёгкую утилиту наподобие tortoisehg.

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

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от grem

А упомянутый выше libgit, почему-то так и не сподвиг никого написать лёгкую утилиту наподобие tortoisehg.

А зачем он нужен, если GUI для Git’а обычно реализовано в той IDE, в которой ты пишешь код.

В графическом представлении никому не было бы дела до того, что там внутри творится.

Дело есть. Есть хорошие реализации Git GUI в IDE, через тот же libgit, а есть медленные и убогие вроде парсим выхлоп консольной утилиты git и теряем в производительности и надёжности.

EXL ★★★★★ ()

Чтобы нормально пользоваться меркуриалом надо обвешаться костылями. Оно «из коробки» не умеет rebase и interactive rebase.

Эти наркоманы принципиально не поддерживают переименование веток. Ну то есть воркфлоу типа

git branch sone_crazzy_stuff
git commit ...
git rebase -i
git branch -m NewFeature

Не прокатит.

invy ★★★★★ ()
Последнее исправление: invy (всего исправлений: 2)
Ответ на: комментарий от EXL

обычно реализовано в той IDE, в которой ты пишешь код

Не все вещи пишутся в ide. Править .ebuild, CMakeLists.txt, Makefile.am, SConstruct файлы и делать мелкие правки мне удобнее в mcedit - всё равно проверять сборку буду средствами portage, как и накладывать патчи. Как и перекидывать в том же mc файлы из локального оверлея, предназначенного для тестирования, в конечный репозиторий: «gentoo portage tree» или «gentoo guru»

Да и реализация в ide не всё что обычно используется может поддерживать. Хотя основное, включая rebase в том же vscode, кажется, есть.

grem ★★★★★ ()
Ответ на: комментарий от EXL

Есть же https://libgit2.org/

Первая реакция моя была «блин, как же мне стыдно за то, что я не знал про такую годноту». Это либа, которую опенсорснул github почти 10 лет назад. Однако, попытка найти клиента под эту либу пока что успехом не увенчалась. Популярные инструменты работают через запуск git, и даже GitHub Desktop работает через спавн git. Для всех операций, несмотря на рассказы разрабов в бложике про libgit2 — никакого использования nodegit (обертки над libgit2 для ноды) я не увидел, а вот процессы плодятся как кролики. Поставил плагины под атом, которые используют nodegit, и получил какой-то лютейший глюкодром.

Буду благодарен, если кто-то подскажет годную тулзу для работы с git под оффтоп, потому что гитом мне еще какое-то время пользоваться придется.

byko3y ★★ ()
Ответ на: комментарий от byko3y

Буду благодарен, если кто-то подскажет годную тулзу для работы с git под оффтоп, потому что гитом мне еще какое-то время пользоваться придется.

Microsoft Visual Studio Community 2019

EXL ★★★★★ ()
Ответ на: комментарий от grem

Мне как-то говорили, что он хранит в коммите название ветки. Не знаю почему, но человек рассказавший об этом, считал,что это «очень важно!». Открываю одну из его реп и вижу 2 ветки с именем default (hg позволяет так делать)

Вроде я тебе уже отвечал, что ветки в mercurial — это не то же, что ветки в git. Ветка в mercurial — это всё дерево правок, сделанных без смены ветки, с расхождениями правок и слияниями. Ветка в git — это линейная последовательность правок.

byko3y ★★ ()
Ответ на: комментарий от EXL

Microsoft Visual Studio Community 2019

Да. Но, блин, так не хочется ставить зонд в анус.

byko3y ★★ ()
Ответ на: комментарий от grem

Без этой консольной утилиты все остальные обвесы в виде веб-сервера и плагинов бесполезны

Знаешь, я годами пользовался TortoiseSVN, ни разу так и не запустив консольную утилиту. И почему-то не жалуюсь.

byko3y ★★ ()
Ответ на: комментарий от byko3y

Мне? Мне всё равно что где. Это детали реализации,которые меня, как пользователя мало не интересуют. Что сделано а коммите должно быть написано в описании тем, кто его делал, а не название ветки. Надеюсь на него почти никто не полагается.

grem ★★★★★ ()
Ответ на: комментарий от EXL

То бишь у mercurial нету какой-нибудь там libhg.so, реализующий нормальные интерфейсы взаимодействия вместо убогих «вызываем консольную утилиту, парсим выхлоп»?

Mercurial написана на питоне, потому у нее нет никаких *.so. Есть низкоуровневые питоновые расширения-бинарники, но у них опять-таки питоний интерфейс. Парсить выхлоп консольных утилит бесполезно, потому что он меняется с версиями.

byko3y ★★ ()
Ответ на: комментарий от EXL

А зачем он нужен, если GUI для Git’а обычно реализовано в той IDE, в которой ты пишешь код

... или не реализован. Или реализован, но плохо.

Есть хорошие реализации Git GUI в IDE, через тот же libgit, а есть медленные и убогие вроде парсим выхлоп консольной утилиты git и теряем в производительности и надёжности

«Надежности» говоришь? Мне интересно, как студия будет переваривать смены версий гита.

byko3y ★★ ()
Ответ на: комментарий от byko3y

После собранного в одно окошко tortoisehg workbench тыкать tortoisegit в файловом менеджере у меня не было желания. Поэтому я предпочёл ему консоль.

grem ★★★★★ ()
Ответ на: комментарий от invy

Оно «из коробки» не умеет rebase и interactive rebase

«А какая ж тут шморгалка?»

Из коробки rebase отключен и включается правкой конфига. Потому что rebase не нужен, а то, что ты хочешь сделать, делается через mqueue, shelve, или работой с грязной локальной репой. Можешь уже придумывать, что ты будешь делать в случае, если сделаешь rebase не туда. На всякий случай сразу отвечу, что будет, если сделать update не туда с грязной репой в mercurial:

hg resolve --unmark --all
hg resolve --all --tool internal:local
hg update $BACK
hg resolve --unmark --all
hg resolve --all --tool internal:local

и ты получаешь репу в исходном состоянии.

Конкретно я на git работаю с локальными ветками через stash (который shelve в mercurial).

byko3y ★★ ()
Ответ на: комментарий от grem

Мне? Мне всё равно что где. Это детали реализации,которые меня, как пользователя мало не интересуют. Что сделано а коммите должно быть написано в описании тем, кто его делал, а не название ветки. Надеюсь на него почти никто не полагается

Эм-м-м, я плохо понимаю ситуацию, но мне кажется, что кто-то скопировал пример из доков меркуриала по веткам, где комиты в ветках создаются с именами веток в описании комита. Ну тут чего зеркало винить.

byko3y ★★ ()
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от grem

На вид мне больше нравится Smartgit

Но это жава, которая парсит текстовый выхлоп git. Как и GitHub Desktop, как и целая гора прочих утилит. Но на вид — да, SmartGit очень хорош.

byko3y ★★ ()
Ответ на: комментарий от byko3y

Да. Но, блин, так не хочется ставить зонд в анус.

Так у тебя же оффтопик. Там-то какая разница, какое количество зондов у тебя в заду? А зонд MS Visual Studio Community гораздо более приятный, чем зонд Windows 10.

… или не реализован. Или реализован, но плохо.

Если в инструменте плохо реализована поддержка самой популярной VCS, то это наверное довольно плохой инструмент.

«Надежности» говоришь? Мне интересно, как студия будет переваривать смены версий гита.

Так в MS же исходный код Windows на Git перевели: Microsoft переводит разработку Windows на Git

Так что думаю, что они за этим зорко следят. Да и Git особо со сменой версий как-то не сильно уж и меняется. А libgit2 вроде конфиг читает, там где всякое поведение git push/git merge в новых версиях изменилось, он это всё подсасывает.

Mercurial написана на питоне, потому у нее нет никаких *.so. Есть низкоуровневые питоновые расширения-бинарники, но у них опять-таки питоний интерфейс.

Это печально. У Git с маловесной libgit2 без зависимостей перспектив довольно много. А вкорячивать Python, тем более древний, это ужасно. Ртуть хоть перешла наконец-то на Python 3 в сборках под Windows?

EXL ★★★★★ ()
Ответ на: комментарий от byko3y

Так я же и говорю. Обвешаться костылями - вся суть Mercurial.

А к костыли еще подпорочки для неосиляторов.

Работа с локальными ветками через сташ и шелв - эталонное неосиляторство.

invy ★★★★★ ()
Последнее исправление: invy (всего исправлений: 1)

Потому что сто раз уже было говорено

У гита стройная элегантная внутренняя архитектура, но уебанский интерфейс. Очевидное решение - написать хороший интерфейс для гита и жить счастливо. Но этого никогда не случится. Ибо чтоб его написать, надо прочитать Pro Git до последней главы и разобраться в предмете. А разобравшийся теряет мотивацию, т. к. и существующий гит его отныне устраивает. Поэтому десятки начатых проектов и ни одного дописанного. Решение простое: прочитать Pro Git до последней главы, ёпта.

Pacmu3ka ()
Ответ на: комментарий от byko3y

Если бы гиту переделали фейс, то я бы первый побежал агитировать людей за гит

Хм. Нельзя ли тупо юзать hg-git?

x3al ★★★★★ ()
Ответ на: комментарий от invy

Обвешаться костылями - вся суть Mercurial.
А к костыли еще подпорочки для неосиляторов.

Это не костыли, а штатные инструменты. Или же у тебя другое определение костыля, и ты пишешь сюда из-под костыля под название «браузер», которая стоит на другом костыле под название «ОС».

Работа с локальными ветками через сташ и шелв - эталонное неосиляторство

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

byko3y ★★ ()
Ответ на: комментарий от invy

И да, что такое «грязная локальная репа?». Похоже ты суть DCVS тоже не осилил, живешь в мире SVN

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

byko3y ★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)