Полгода назад уже отвечал. Мухи не ошибаются, потому разработка будет вестись на Git. Точнее, не столько разработка, сколько публичная репа будет на Git, поскольку сам по себе Git для организации патчей приема (ревью, тест, и т.д.) не подходит.
Человеческий интерфейс вместо криптозаклинаний консоли гита. Если бы гиту переделали фейс, то я бы первый побежал агитировать людей за гит. Но этого уже никогда не сделают, потому что ретрограды у руля разработки гита принципиально отказываются делать интерфейсы, отличные от текста аля «юникс-вей», через которые работают все тулзы под гит и потому отвалятся при смене интерфейса.
А интерфейс у гита настолько убогий и опасный в применении, что ныне возникла профессия «админ репы гита». По абсурду это что-то уровня «менеджер поддержки блокнота» или «админ калькулятора» — инструмент, который должен был быть незаметным и просто выполнять свои функции, стал теперь фокусом внимания.
потому что ретрограды у руля разработки гита принципиально отказываются делать интерфейсы, отличные от текста аля «юникс-вей», через которые работают все тулзы под гит
Мне как-то говорили, что он хранит в коммите название ветки. Не знаю почему, но человек рассказавший об этом, считал,что это «очень важно!». Открываю одну из его реп и вижу 2 ветки с именем default (hg позволяет так делать).
Хотя там полный унос мозгов на любой странице из официальных доков. Я понимаю, что в 99% случаев вопросы решаются путем «загугли проблему, скопируй решение. Если не помогло — повтори».
Но факт остается фактом: командная строка у гита запутанная, параметры неочевидны, а официальная документация никак не помогает, если ты не являешься экспертом по калькулятору git.
Это мусор. Всерьез их можно воспринимать только если больше ничего в жизни не видел.
В меркуриале все сложнее чем коммит и пуш делается из такими же заклинаниями
Во-первых, командная строка mercurial проще и понятнее, хоят действия примерно те же нужно делать, да. Во-вторых, командная строка является далеко не единственным интерфейсом.
То бишь у mercurial нету какой-нибудь там libhg.so, реализующий нормальные интерфейсы взаимодействия вместо убогих «вызываем консольную утилиту, парсим выхлоп»?
Есть, как минимум, command server (A server that allows communication with Mercurial’s API over a pipe), который позволяет выпускать внешние тулзы под любой лицензией. Может и в другом виде есть доступ к API для внешних библиотек.
Но внешние тулзы - это внешние тулзы, а не сам mercurial или git. А упомянутый выше libgit, почему-то так и не сподвиг никого написать лёгкую утилиту наподобие tortoisehg.
Это я к тому, что здесь срач в основном идёт между интерфейсами командной строки. В графическом представлении никому не было бы дела до того, что там внутри творится.
А упомянутый выше libgit, почему-то так и не сподвиг никого написать лёгкую утилиту наподобие tortoisehg.
А зачем он нужен, если GUI для Git’а обычно реализовано в той IDE, в которой ты пишешь код.
В графическом представлении никому не было бы дела до того, что там внутри творится.
Дело есть. Есть хорошие реализации Git GUI в IDE, через тот же libgit, а есть медленные и убогие вроде парсим выхлоп консольной утилиты git и теряем в производительности и надёжности.
обычно реализовано в той IDE, в которой ты пишешь код
Не все вещи пишутся в ide. Править .ebuild, CMakeLists.txt, Makefile.am, SConstruct файлы и делать мелкие правки мне удобнее в mcedit - всё равно проверять сборку буду средствами portage, как и накладывать патчи. Как и перекидывать в том же mc файлы из локального оверлея, предназначенного для тестирования, в конечный репозиторий: «gentoo portage tree» или «gentoo guru»
Да и реализация в ide не всё что обычно используется может поддерживать. Хотя основное, включая rebase в том же vscode, кажется, есть.
Первая реакция моя была «блин, как же мне стыдно за то, что я не знал про такую годноту». Это либа, которую опенсорснул github почти 10 лет назад. Однако, попытка найти клиента под эту либу пока что успехом не увенчалась. Популярные инструменты работают через запуск git, и даже GitHub Desktop работает через спавн git. Для всех операций, несмотря на рассказы разрабов в бложике про libgit2 — никакого использования nodegit (обертки над libgit2 для ноды) я не увидел, а вот процессы плодятся как кролики. Поставил плагины под атом, которые используют nodegit, и получил какой-то лютейший глюкодром.
Буду благодарен, если кто-то подскажет годную тулзу для работы с git под оффтоп, потому что гитом мне еще какое-то время пользоваться придется.
Мне как-то говорили, что он хранит в коммите название ветки. Не знаю почему, но человек рассказавший об этом, считал,что это «очень важно!». Открываю одну из его реп и вижу 2 ветки с именем default (hg позволяет так делать)
Вроде я тебе уже отвечал, что ветки в mercurial — это не то же, что ветки в git. Ветка в mercurial — это всё дерево правок, сделанных без смены ветки, с расхождениями правок и слияниями. Ветка в git — это линейная последовательность правок.
Мне? Мне всё равно что где. Это детали реализации,которые меня, как пользователя мало не интересуют. Что сделано а коммите должно быть написано в описании тем, кто его делал, а не название ветки. Надеюсь на него почти никто не полагается.
То бишь у mercurial нету какой-нибудь там libhg.so, реализующий нормальные интерфейсы взаимодействия вместо убогих «вызываем консольную утилиту, парсим выхлоп»?
Mercurial написана на питоне, потому у нее нет никаких *.so. Есть низкоуровневые питоновые расширения-бинарники, но у них опять-таки питоний интерфейс. Парсить выхлоп консольных утилит бесполезно, потому что он меняется с версиями.
А зачем он нужен, если GUI для Git’а обычно реализовано в той IDE, в которой ты пишешь код
... или не реализован. Или реализован, но плохо.
Есть хорошие реализации Git GUI в IDE, через тот же libgit, а есть медленные и убогие вроде парсим выхлоп консольной утилиты git и теряем в производительности и надёжности
«Надежности» говоришь? Мне интересно, как студия будет переваривать смены версий гита.
Из коробки rebase отключен и включается правкой конфига. Потому что rebase не нужен, а то, что ты хочешь сделать, делается через mqueue, shelve, или работой с грязной локальной репой. Можешь уже придумывать, что ты будешь делать в случае, если сделаешь rebase не туда. На всякий случай сразу отвечу, что будет, если сделать update не туда с грязной репой в mercurial:
Мне? Мне всё равно что где. Это детали реализации,которые меня, как пользователя мало не интересуют. Что сделано а коммите должно быть написано в описании тем, кто его делал, а не название ветки. Надеюсь на него почти никто не полагается
Эм-м-м, я плохо понимаю ситуацию, но мне кажется, что кто-то скопировал пример из доков меркуриала по веткам, где комиты в ветках создаются с именами веток в описании комита. Ну тут чего зеркало винить.
Так у тебя же оффтопик. Там-то какая разница, какое количество зондов у тебя в заду? А зонд MS Visual Studio Community гораздо более приятный, чем зонд Windows 10.
… или не реализован. Или реализован, но плохо.
Если в инструменте плохо реализована поддержка самой популярной VCS, то это наверное довольно плохой инструмент.
«Надежности» говоришь? Мне интересно, как студия будет переваривать смены версий гита.
Так что думаю, что они за этим зорко следят. Да и Git особо со сменой версий как-то не сильно уж и меняется. А libgit2 вроде конфиг читает, там где всякое поведение git push/git merge в новых версиях изменилось, он это всё подсасывает.
Mercurial написана на питоне, потому у нее нет никаких *.so. Есть низкоуровневые питоновые расширения-бинарники, но у них опять-таки питоний интерфейс.
Это печально. У Git с маловесной libgit2 без зависимостей перспектив довольно много. А вкорячивать Python, тем более древний, это ужасно. Ртуть хоть перешла наконец-то на Python 3 в сборках под Windows?
У гита стройная элегантная внутренняя архитектура, но уебанский интерфейс. Очевидное решение - написать хороший интерфейс для гита и жить счастливо. Но этого никогда не случится. Ибо чтоб его написать, надо прочитать Pro Git до последней главы и разобраться в предмете. А разобравшийся теряет мотивацию, т. к. и существующий гит его отныне устраивает. Поэтому десятки начатых проектов и ни одного дописанного. Решение простое: прочитать Pro Git до последней главы, ёпта.
Обвешаться костылями - вся суть Mercurial. А к костыли еще подпорочки для неосиляторов.
Это не костыли, а штатные инструменты. Или же у тебя другое определение костыля, и ты пишешь сюда из-под костыля под название «браузер», которая стоит на другом костыле под название «ОС».
Работа с локальными ветками через сташ и шелв - эталонное неосиляторство
Если вспомогательный инструмент требует осиливать и превозмогать, то он автоматически становится говном и ненужным. Тут люди работу работают, а не осиливают день ото дня.