Отличия git от hg

Даже ещё веселее:
$ hg help extenstions
hg: unknown command 'extenstions'

Хоть и не так удобно, как в гите, но и то хорошо.

То есть для тебя редактирование патча в редакторе удобнее простого выбора чанков? «Git rots the brain» (c) почти Дейкстра

Мне удобно, когда есть и то, и другое.

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

P.S. И, кстати, ярлык «фанбой» вешаю не на всех, кто не согласен с моим мнением, а только лишь на фанбоев.

Ой, он еще и не знает, как extensions пишется. Дядь, ну ты совсем.

Ой, он еще и не знает, как extensions пишется. Дядь, ну ты совсем.

Фанбой, умеешь отличать опечатки от ошибок?

Ты, кушай-кушай, не отвлекайся.

Анонимусы такие анонимусы.

А tailgunner спасибо за адекватность.

Старый говном кормить не будет, да, он добрый.

Ты сказал «только те изменения в файле, которые мне надо», т.е. только часть имеющихся в файле изменений. Приведенная тобой команда добавляет все, qrecord - только те, что надо. В чем твоя претензия к «простоте»?

git add -p запрашивает пользователя, какие именно части патча применять.

О да, это так беспристрастно - приплести социальную сеть github к сравнению DVCS-систем git и hg. И эти люди обвиняют нас в фанбойстве %)

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

Интересно, умеет ли git коммитить криво отредактированные чанки.

Mercurial:
* БОльшая часть операций в нем выполняется проще и к документации надо обращаться реже.
* Требует написание меньшего кол-ва скриптов/алиасов для удобной работы из консоли.
* Та же функциональность, что в git, достигается через плагины. Иногда удобнее, иногда криво (особенно если плагин не входит в состав меркуриала).
* Имеет довольно хороший гуи под винду (tortoise hg), почти как tortoise svn.
* Обычно гуи/IDE поддерживают совсем не все плагины, поэтому все равно приходится использовать консоль.
* hgsubversion значительно лучше чем git-svn.
* Часто ломается совместимость, прямо или косвенно, что вылезает в плагинах (том же hgsubversion). На работе натыкался дважды, в результате просто везде собираю одинаковую версию из исходников.
* Иногда напрягает нежеланием разработчиков добавить какую-то опцию, которая испортит логичность интерфейса, но без которой какой-нибудь репозиторий тупо не работает. (конкретно, нельзя сделать pull без обновления подмодулей)

Git:
* Не разделен на плагины. В целом, функциональность намного более проработана, чем аналогичная в разрозненных плагинах hg (часто вспоминают 5 реализаций веток в hg).
* Такие вещи, как локальные ветки, rebase -i, remotes, rerere и многие другие, в hg, в целом, достижимы, но, ИМХО, в git в разы удобнее и проработаннее (в т.ч. по сравнению с mq).
* Часто приходится заглядывать в документацию, опций много и одна команда обычно выполняет много разных действий. Обычно каждый составляет свои скрипты/алиасы.
* Нормально работать, имхо, можно только из консоли + просмотрщик истории, конечно. Хороших гуи не видел. Под винду гуи особенно хреновые.
* Есть опции на все случаи жизни. Проблема только найти их.
* Совместимость при мне не ломалась.

Я наблюдал, как люди, раньше использовавшие svn, или ничего не использовавшие, пробуют использовать гуи
для git (tortoise git, smart git), не прочитав док/прочитав какой-нибудь короткий quickstart.

Это плохая идея. Через раз вылезают сообщения об ошибках от консольных команд, которые эти гуи дергают (про stage, про crlf, про detached HEAD и т.п.),
и их смысл людям не ясен, если человек не читал git book и оф. мануал. После прочтения же удобнее использовать консоль. С mercurial таких косяков на порядок меньше,
еще меньше их с svn, если дело не доходит до веток =)

Итого, git имеет смысл использовать, если все участники команды
* имеют возможность потратить время на чтению манов
* могут комфортно использовать консоль

http://code.google.com/p/support/wiki/DVCSAnalysis
http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-cont...

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

Он нынче и не говно. Просто объективно хуже hg.

часто вспоминают 5 реализаций веток в hg

Классический FUD

локальные ветки, rebase -i, remotes, rerere и многие другие, в hg, в целом, достижимы, но, ИМХО, в git в разы удобнее и проработаннее (в т.ч. по сравнению с mq).

То же самое.

Под винду гуи особенно хреновые.

git extensions же

Поэтому «ИМХО». Это не объективные аргументы; дело вкуса.

Хочется понять чем отличается git от hg.

http://gitvsmercurial.com/

git extensions

Надо будет внимательнее посмотреть. Подробно смотрел smart git и tortoise.

Классический FUD

Ты издевашься что ли? Как мне в hg получить нормальные локальные ветки, которые можно синхронизировать?

Тем не менее, локальные ветки в hg кривые =)

Как мне в hg получить нормальные локальные ветки

Хех.

Ты издевашься что ли?

Над кем или чем?

Как мне в hg получить нормальные локальные ветки, которые можно синхронизировать?

После «нормальные» отвечать уже бессмысленно, но всё же хотелось бы знать, что ты понимаешь под «синхронизировать».

БОльшая часть операций в нем выполняется проще и к документации надо обращаться реже.

http://www.wikivs.com/wiki/Git_vs_Mercurial — git commit --amend vs hg qimport -r tip ; hg qrefresh -e ; hg qfinish tip (Requires the MqExtension.). Простота так простота!

Имеет довольно хороший гуи под винду (tortoise hg), почти как tortoise svn

tortoise git тоже существует

Итого, git имеет смысл использовать, если все участники команды имеют возможность потратить время на чтению манов

А не кажется ли тебе, что система контроля версий — это инструмент, которым таки стоит уметь пользоваться. Я согласен, что после SVN git просто ад кромешный. Но если не читать мануалов и «пользоваться по наитию», то как ты узнаешь о клевых штуках типа stash/attic и прочего, отличающего свежие VCS от морально устаревшего шлака?

мне найти не удалось.

да ладно

меркуриал на тормозном питтоне, а гит на реактивной сишечке.

однако это не мешает гиту тормозить

http://www.wikivs.com/wiki/Git_vs_Mercurial — git commit --amend vs hg qimport -r tip ; hg qrefresh -e ; hg qfinish tip (Requires the MqExtension.). Простота так простота!

А напиши, как отредактировать не-последний коммит? %)

согласен, что после SVN git просто ад кромешный.

Дело даже не в этом, а в том, что гит-фанбои считают это _нормальным_. Вот это и есть «Git rots the brain» - всегда выбирается самый непохожий и/или ублюдочный способ реализации фичи, и он объявляется единственным Ъ способом.

Простота так простота!

это шоле замена последнего коммита? Делается гораздо проще. hg strip и коммит по-новой. Можешь создать алиас на эту комманду если часто такое делаешь.

и он объявляется единственным Ъ способом

С этого места поподробнее. Кем объявляется, и где можно найти это объявление.

Кем объявляется

Изначально - Линусом, сейчас ряды фанбоев сильно выросли.

и где можно найти это объявление.

Раньше - в git@, сейчас я уже перестал следить.

БОльшая часть операций...
git commit --amend
Окей, поправка: простые/типичные операции в нем выполняются проще. amend - нужен не всем/не так часто.

tortoise git тоже существует

Мы натыкались в нем на кучу багов, в том числе иногда молча не работал даже pull. Если его допилят, я буду рад, но есть одно но: tortoise hg и svn используют api, а tortoise git дергает консольные команды и парсит их вывод, что есть плохой дезайн.

А не кажется ли тебе, что система контроля версий — это инструмент, которым таки стоит уметь пользоваться

Зависит от ситуации, многим достаточно push/pull/merge. Я не считаю, что это плохо, до тех пор, пока человек при этом пишет хороший код и нормально его поддерживет =)

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

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

Над кем или чем?

Над здравым смыслом. Тебе сказали, что в hg 5 реализаций локальных веток, а ты говоришь, что это FUD. А разве это не так? Разве это нормально, когда для многих важных фичей >1 реализации и все из них являются сторонними плагинами?

После «нормальные» отвечать уже бессмысленно, но всё же хотелось бы знать, что ты понимаешь под «синхронизировать».

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

Синхронизировать - возможность опубликовать локальную ветку в другом репозитории и в дальнейшем поддерживать их в синхронном состоянии

А напиши, как отредактировать не-последний коммит?

git rebase -i - редактирует все что захочется

многие вещи можно сделать разными способами

Ага, как в перле.

А напиши, как отредактировать не-последний коммит? %)

git rebase -i revision => находим коммит который хотим менять и устанавливаем для него action в edit => правим => git commit --amend => git rebase --continue

Дело даже не в этом, а в том, что гит-фанбои считают это _нормальным_.

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

И потом, когда я читал git book, у меня сложилось впечатление, что этот инструмент делался разработчиком для разработчиков: просты повседневные действия производятся просто, продвинутые делаются на базе простых, а если очень захотеть, можно творить хардкор, кромешный ад и погибель. И потом, проблема git для svn пользователей решается cheatsheet'ом, в котором будет svn revert file <=> git checkout file и т. д.

Если его допилят, я буду рад, но есть одно но: tortoise hg и svn используют api, а tortoise git дергает консольные команды и парсит их вывод, что есть плохой дезайн.

Напоминает нытье про mplayer: тоже никакой библиотеки, никакого api, управление, в лучшем случае, через пайп, куча ключей командной строки и... лучший плеер.

Зависит от ситуации, многим достаточно push/pull/merge. Я не считаю, что это плохо, до тех пор, пока человек при этом пишет хороший код и нормально его поддерживет.

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

почему вы перешли в итоге на git

Мне показалось там проще править историю, проще работа с ветками. Да и больших различий в синтаксисе я не нашел, что бы не говорили hg-фаны.

Тебе сказали, что в hg 5 реализаций локальных веток, а ты говоришь, что это FUD. А разве это не так?

Мне не привели список. Как минимум 1 реализация локальных веток (репозиторий на ветку) - общая для вобще всех DVCS, так что в Git как минимум 2 реализации локальных веток.

Разве это нормально, когда для многих важных фичей >1 реализации и все из них являются сторонними плагинами?

Какие «все», блин? Какими «сторонними»? Список приведи.

И да, плагинная система - это хорошо. Благодаря ей даже такие базовые возможности, как разные способы организации веток можно обкатывать, не тревожа основную кодовую базу // К.О.

нормальные локальные ветки, которые можно синхронизировать?

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

Т.е. в том же репозитории. И, внезапно:

Синхронизировать - возможность опубликовать локальную ветку в другом репозитории

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

Ну а опубликовать локальную последовательность коммитов можно командой hg push. Внезапно, да?

Ну и получится в итоге, что неопытный человек закоммитит по ошибке...

Да так и бывает, коммитит народ все подряд без разбору, что в svn, что в hg :)

А напиши, как отредактировать не-последний коммит?

git rebase -i - редактирует все что захочется

Для того, чтобы поправить лог-мессагу, предлагается использовать rebase? O_o Впрочем, в hg тоже есть rebase.

Для того, чтобы поправить лог-мессагу, предлагается использовать rebase?

Там, кстати, не только лог-мессагу править можно.

А напиши, как отредактировать не-последний коммит? %)

git rebase -i revision => находим коммит который хотим менять и устанавливаем для него action в edit => правим => git commit --amend => git rebase --continue

И всё это - тоже проще, чем в hg, конечно же?

Дело даже не в этом, а в том, что гит-фанбои считают это _нормальным_.

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

Бгг. Родной, это _ты_ с Линусом подобны вендузятнегам. Я даже объясню, почему: вот существует многолетняя традиция VCS (и коротенькая традия DVCS); но приходит Линус и говорит «я сцуко ненавижу CVS и буду делать всё по-новому, а все, кто не согласен - тупые уроды!!!11»; и набигают хомячки^Wфанбои, которые говорят «да, Линус, ты всё правильно делаешь!!!1». И ровно та же фигня была с ОС - существовал UNIX, но потом пришел Гейц и сказал «вы всё делаете не так, я покажу, как надо», хомячки прилагаются. Так что... Git - это венда от DVCS, а его фанбои - вендузятнеги.

И потом, когда я читал git book, у меня сложилось впечатление, что этот инструмент делался разработчиком для разработчиков

Этот инструмент делался Линусом для себя; ссобственно, в этом и основной секрет его популярности - каждый может почувствовать себя Линусом. То, что это ложное чувство, значения уже не имеет.

Там, кстати, не только лог-мессагу править можно.

Я знаю. И в hg qref - тоже.

И всё это - тоже проще, чем в hg, конечно же?

А ты попробуй.

Так что... Git - это венда от DVCS, а его фанбои - вендузятнеги.

То есть, стандарт де факто и все, кто не как гит — девиантные отщепенцы? :)

Этот инструмент делался Линусом для себя

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

в этом и основной секрет его популярности - каждый может почувствовать себя Линусом

А может в том, что лучше, чем девелопер для девелопера никто не сделает?

Ты хочешь сказать, что Мэтт Макколл - не девелопер? Не девелопер - это твой Линус, который давно код не пишет, только рецензирует чужие патчсеты.

И всё это - тоже проще, чем в hg, конечно же?

А ты попробуй.

С меня хватило описания.

Git - это венда от DVCS, а его фанбои - вендузятнеги.

То есть, стандарт де факто и все, кто не как гит — девиантные отщепенцы? :)

Вот-вот, типичный аргумент типичного вендузятнега.

И нет, гит-фанбои - не девиантные отщепенцы, они просто неспособны к самостоятельному мышлению %)

Ошибочка, уважаемый: не для себя, а для решения конкретной задачи

Человек, не читавший git@ в 2005-м, указывает на ошибки? Ты смешон.

А может в том, что лучше, чем девелопер для девелопера никто не сделает?

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

И нет, гит-фанбои - не девиантные отщепенцы, они просто неспособны к самостоятельному мышлению %)

Ох, педонофил бы говорил: «Я люблю педон, значит весь софт на педоне божественен, значит только пресвятой Mercurial!» :P

Человек, не читавший git@ в 2005-м, указывает на ошибки?

В 2005-м я конспекты лекций читал. Но с новостных ресурсов а-ля лор долетали такие истории: «bitkeeper окуклился, Линус нахохлился и сделал свою DVCS за выходные». И то, что он жестко и по-мужски отвергает всякие метросексуальные косметические говнофичи и прогибы перед безграмотной аудиторией, меня даже восхищает. Можешь считать меня фанбоем, если нравится, но мнение Линуса при разработке git будет повесомее, чем вопли «proud subversion users».

Мэтт Макколл

Кто такой? Чем знаменит?

Mercurial уже научился подписывать с помощтю GPG коммиты/теги/etc?

«Я люблю педон, значит весь софт на педоне божественен,

Я такого не говорил и не думал, ты лгешь нам. Например, bzr (на Python) - тормоз.

значит только пресвятой Mercurial!» :P

Я мигрировал на Mercurial с Git (до того несколько лет пользовался SVN и ставил «на посмотреть» svk, OpenCM, Monotone, Arch/tla).

В 2005-м я конспекты лекций читал

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

Можешь считать меня фанбоем

Бгг. Да тебя нужно не «считать фанбоем».а в рамочку и на стену - «вид»: фанбой git, подвид: Ъ-мачо".