@Sectoid, быстренько поднять сервер на http для междусобойчика — hg serve

@trminator, И чего, пушить тоже черег http?

@Sectoid, Есть. Чтение и понимание инструкции.

@xl0, ну да

@Sectoid, на себе испытал гормознутось hg при большом репозитории. Правда давно это было. Уже года два назад

@Sectoid, к меркуриалу элементарно писать расширения, на нормальном языке, работают везде и работают удобно.

@trminator, git daemon

@Sectoid, о, меркуриал нормально работает по виндой и макосью... Гит тоже работает, но никак по другому как "уродство" это не назовешь

@ComradeDOS, ой. А оно давно есть?

@Shchvova, git hooks

@trminator, Давно.

@ComradeDOS, насколько я понимаю это не одно и то же. Функциональность хуков очень ограничена, когда расширения меркуриала могут очень много что менять, например, как хранится информация в репозитории.

@Shchvova, Скажем так — с помощью хуков можно сделать многое. Если нужно больше лезь внутрь.

@Sectoid, легче найти адекватный пользователей, а не тупых фан-боев Торвальдса.

@Shchvova, Еще меркуриал использует человеческую терминологию, да и команды имеют парные названия. Но ТС явно хотел список рецептов.

@Sectoid, Кто-нибудь, напомните, как в гите отредактировать предпоследний коммит?

@balodja, git rebase -i HEAD~3

@Sectoid, да, еще еще меркуриал нормально использует ветки. Звучит тупо, но гит в этом плане просто говно... Ну общим, вот что умные люди пишут jhw.dreamwidth.org

@Sectoid, К тому, ТС, для кого ты собираешься это мнение формулировать? :)

@ComradeDOS, Ребейз? Шикарно, после этого можно про тормознутость меркуриала даже не заикаться.

@Shchvova, Ну git под вин тоже уже отлично работает, хотя такое было не всегда.

@balodja, Ы?

@Shchvova, Извините, вы ебанулись?

@xl0, Он ебанутый, но сейчас он прав.

@balodja, Кривость веток в hg вроде всегда был основным аргументом против. Даже более, чем кривой merge и тормоза.

@xl0, По сети ходит популярная среди гитоёбов ссылка, мол, что в меркуриале 5 способов делать ветки. Сколько раз уже приходилось опровергать этот бред, но все упорно игнорируют. Да и пофиг, тащемта.

@Sectoid, а, да, еще в меркуриале нету необходимости делать рибейз... Вообще это ущербная идеология править историю, не?

@balodja, И не один не работает как надо.

@Shchvova, Ну, если локальную и текущую, то почему бы и нет?

@xl0, Вот-вот, еще один дебил.

@balodja, а сколько их на самом деле? и заодно скажите сколько вообще разных видов веток, я навскидку 3 помню

@balodja, потому что это история коммитов. Нахуй она нужна если ее править? Не, жрать говно не вкусно, ну разве только локально, что бы никто не видел — заебись логика.

@Sectoid, Основные претензии к hg: 1) Кривые бранчи. 2) Кривой merge. 3) Невозможность запушить только тот бранч, который ты хочешь запушить. 4) тормоза на больших проектах. 5) hg log выглядит просто ёбищьно. 6) И это только то, что я вспомнил сейчас.

@xl0, И да, часть проблем решается разными расширениями. Часть расширений даже идёт обычно по дефолту, но надо нагуглить и всключить.

@xl0, такое может написать человек только что бы оправдать что он ртсосал уже Торвальдсу и терминально туп...

@max630, Я знаю ровно один. hg branch

@Shchvova, Так и в гите нет необходимости делать rebase. @balodja запросил как изменить предпоследний коммит (как поправить историю) и ему ответили.

@Sectoid, Тред скатился в унылое говно. Обычный срачик между сторонниками разных подходов. Очень напоминает спор "остроконечников" с "тупоконечниками".

@Kim, Ну это фича гита, там можно легким движением руки редактировать историю в удаленных репозиториях, например. Шикарнота же! Но при этом нельзя нормально поправить мессагв в предпоследнем коммите.

@balodja, stgit. Ну, или руками checkout, edit, rebase.

@balodja, "я не правлю историю, я просто переписываю commit мессиджи"

@Sectoid, ну общим, отошли от темы. Меркуриал лучше гита банально тем что он мержит умнее.
Читать jhw.dreamwidth.org

@Shchvova, Чтобы твою последнюю локальную историю сделать чистой и аккуратной перед тем, как коммитить в общий репозиторий. Может ты еще и mq не пользуешь?

@xl0, stgit — это такой хилый закос под mq.

@xl0, ага. а критерием кривости/ровности является степень похожести на git. git лучшевсех потому что это git и он лучшевсех. какая срань.

@LittleChris, Это же хомячки торвальдса, чего еще ожидать?

@xl0, конкретику в тред

@LittleChris, Я зибил и просто использую

@LittleChris, ну, я написал уже 4 конкретных факта чем лучше меркурил гита, на что получил ответ "говно, т.к. не так как в гите"

@LittleChris, Я зибил и просто использую миррор в гит по работе. С кроме работы hg не встречаю.

@xl0, и какое отношение твое жалкое существование имеет к треду?

@Shchvova, Нахуй пошел.

@balodja, А хомячки Mackall'а лучше хомячков Торвальдса?

@Kim, я даже не знаю кто это, так что вероятно анальные рабы Торвальдса суровее..

@balodja, Если нужно отредактировать только сообщение — git commit --amend В /16 говорилось про редактирование коммита, а не сообщения.

@Shchvova, Это ведущий разработчик hg. Я, например, вчера узнал, как его зовут. Ты, судя по всему, сегодня.

@ComradeDOS, Предпоследнего коммита?

@balodja, да. Отлично что им пользуются профессионалы как инструментом, а не толпа долбоебов которые дрочат на имя автора.

@Kim, хомячки вообще зло. и даже на топливо для биореактора едва годятся.

@balodja, Последнего. В git help commit есть описание того, что тебе нужно. ;)

@Shchvova, есть ещё класс юзеров «гит охуенный потому, что гитхаб охуенный».

@ComradeDOS, Рецепт в студию. Я чото сам не осилил.

@ComradeDOS, наваяешь на хуках git аналог hg-git.github.com — тогда и поговорим.

@Shchvova, Это те которые ведут диалог в формате "Ты хуй, hg это единственно верная система". Все уже увидели две ссылки с описанием одной и той же проблемы. ТС наверно даже сделал пометку, что Git does not records family history in the repository и дальше его не интересует, как ты называешь собеседников, долбаёбами которые дрочат на и далее по тексту.

@balodja, git reset --soft ID && git commit --amend

@Kim, не правда, собеседников я так пока не называл.

@Kim, вы чота путаете, тезис таков: «git — уёбищное говно, пушо здесь он неудобный, а тут — кривой, а вот этого не умеет в принципе. я с вас удивляюсь, хули вы все на него фапаете»

@Shchvova,
а, да, еще в меркуриале нету необходимости делать рибейз... Вообще это ущербная идеология править историю, не?
«В колбасе потребности нет» ©

@LittleChris, Зачем, если есть git-hg?)

@ComradeDOS, Ты же таким образом склеишь два коммита, если я правильно понял.

@LittleChris, Ну понятно же, что кроме "не умеет в принципе" про историю — остальное были аргументы уровня "мне удобно спать на потолке, а кто не согласен — болен на голову".

@fractal, Ты вообще представляешь, какую попоболь причиняет правка нелокальной истории в dvcs?

@balodja,
_>

@Shchvova, «Чем лучше? Чам армяне!»

Отличный пост, без единого примера «вот тут hg распарсил, а git бы не смог».

@trminator, с некоторой натяжкой можно принять. а почему именно http?

@Kim, «мне удобно набивать в 1,5 раз больше команд при рутинных операциях из-за прибитой 150мм гвоздями staging area, получая профит от её использования раз в месяц; а кто не согласен — болен на голову»

@Shchvova, принимается.

@Shchvova, принимается. самый серьезный недостаток, как по мне.

@Shchvova, впрочем как раз у гита больше свобода для написания расширений: есть low-level комманды, которые общаются с внешним миром текстом. Следовательно на чем писать расширения — дело личное автора.

@balodja, рецепт на самом деле такой:

git rebase -i HEAD~3
<сказать reword на нужный коммит>
<изменить сообщение>

@Kim, Это я уже понял, да.

@Shchvova, странный комментарий. аналогично в меркуриал-сообществе овер9к неадекватных фанатов бидона

@LittleChris, Да, так лучше.

@Sectoid, я так понимаю, libgit2.github.com пишется гитхабовцами от нехер делать?

@balodja, а не надо так делать.

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

@fractal, Напомню, твой архиостроумный комментарий про колбасу относился именно к такой ситуации.

@Sectoid, code.google.com

@Sectoid, особенно интуитивно выводится команда git request-pull например

@balodja, для себя, в первую очередь

@LittleChris, А что это за комманда? за 3+ года использования ни разу не сталкивался.
/me пошел читать man.

@Sectoid, Если для себя, то неужели оно еще не сложилось?

@balodja, интуитивно — давно. хотел формализовать.

@Shchvova, я так и не понял на что жалуеццо аффтар. можно на пальцах?

@balodja, датышо? сирьёзна?

«а, да, еще в меркуриале нету необходимости делать рибейз... Вообще это ущербная идеология править историю, не?» — где тут про удалённую историю?

И кстати, иногда может появиться крайняя нужда отредактировать удалённую историю: файл с паролями засунули, выложили бинарь, или просто файло с нарушением лицензии. А какую колбасу нам предложит hg на этот случай?

@Sectoid, Про интуитивность git. Дано:
$ ls
foo bar
$ git branch
bar
* master
Вопрос: что сделает команда git checkout bar?

@Sectoid, Да. Вот при обучении это играет крайне важную роль. Начать пользоваться hg можно гораздо быстрее, чем git'ом. А уж особенно, если до этого люди пользовались каким-нибудь svn.

@LittleChris, выгружает в рабочую копию ветку bar, очевидно же. еще раз — курим модель.

@fractal, можно mq использовать, можно strip+import, можно histedit.

@fractal, Кстати, ребейз в меркуриале есть. Я им, к примеру, еще ни разу не воспользовался, необходимости в этом действительно нет.

@balodja, SVN из людей надо выжигать каленым железом, имхо

@Sectoid, жаль что тредик таки скатился в срач(

@Sectoid, а где это написано?

@Sectoid, Зачем железом? Можно с помощью hg :)

@LittleChris, что именно — это? семнатика checkout — в man git-checkout, модель счас сходу не скажу, но в мане тоже есть.

@Shchvova, я не люблю забивать гвозди надувным молотком. а ты?

@Sectoid, я тоже рибейз не люблю

@Sectoid, что у веток есть приоритет перед файлами.

@Sectoid, Можно подумать, что следовало ожидать чего-то другого.

@Shchvova, как раз рибейз это молоток нормальный, а история, которую нельзя менять, когда мне это нужно — надувной молоток

@balodja, вообще хотелось таки конкретные usecase'ы(

@LittleChris, git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
ы?

@Sectoid, ахуеть очевидно.

@balodja, commit --amend

@Sectoid, тогда в чём именно он заключается? аутентификацию починили вроде

@LittleChris, открывайте дверь! Это акция "знай shell или кипятильник в жопу!"

@Sectoid, Нет же. Предпоследний коммит интересует. В hg я возьму hg qimport, а в git придется брать rebase.

@dr-Chaos, git-svn починили? он ползал дичайше. и еще страшно таращило на cr/lf раньше (причем вне зависимости от настроек). и скорость.

@balodja, а, предпоследний. rebase -i.

@balodja, а что плохого в rebase? это одна из тех вещей, за которые я люблю гит

@Sectoid, мне за шелл не платят. а тебе?

@LittleChris, также как и тебе — за решение задач. а если хуево знаешь инструмент — решаешь их ты тоже хуево.

@Sectoid, ви гойворите так, будто в hg нет этого вашего rebase.

@LittleChris, есть. но без гитовых веток он не так годен.

@Sectoid, или беру нормальный инструмент, но ведь это не рассматривается, не так ли?

@LittleChris, инструмент, которым невозможно выполнить требующуюся мне манипуляцию — говно и не нужен.

@balodja, я сталкивался неоднократно с ситуациями, когда это необходимо. что, из-за чьего-то баттхерта не будем делать то, что нужно?

@Sectoid, гитовские «ветки» — это hg bookmarks.

@LittleChris, да, наслышан уже. правда не тестировал — насколько точно соответствуют?

@LittleChris, его для другого пишут. чтобы была возможность безопасно взаимодействовать с гит-репами из долгоживущих процессов. Существующая libgit написана из расчета использования в короткоживущих утилитах, и имеет в связи с этим немалые утечки памяти

@Sectoid, они оба являются одним и тем же — перемещаемым указателем на вершину DAG ревизий. hg-git пушит в git remote именно bookmarks

@Sectoid, шота я не нахожу libgit в репах

@Sectoid, очевидно, что
re-entrant, with sane error handling
designed with a solid and consistent API
compiled with minimal external dependencies (currently only zlib)сплошь выдумка и маркетинг. ну кому это может понадобиться?

@LittleChris, она немножко статическая, является частью проекта git.

@LittleChris, а теперь еще раз прочитай сообщение, на которое отвечаешь.

@Sectoid, $ locate -b libgit | wc -l
0

@Sectoid, или ты имел в виду, что она вкомпилена в git статически и на диске её запросто может не быть?

@LittleChris, я имел в виду, что в силу того, что она статическая и не особо предназначена для внешнего использования — ее нечасто вкладывают в пакеты в дистрибутивах.

@Sectoid, когда сроки поджимают, а инструмент требует прочесть и усвоить тонны манов чтобы просто работать с ним, он выкидывается нахер.

@LittleChris, ну, я ж говорю — херовый из тебя работник, даже инструментарий первой необходимости не знаешь в базовом объеме. в сад.

@Sectoid, а всё почему? а всё потому, что в кишках у git говно и черви, которое даже в либу толком не завернёшь. вот 5 лет прошло, прежде чем хоть что-то вменяемое появилось.

@Sectoid, диагноз по аватарке? ну-ну.

@ComradeDOS, stackoverflow.com
but the downside of it is that you cannot push updates made to your git repo to a hg repo with git-hgа hg-git умеет пушить коммиты в репозитории git

@LittleChris, если честно — мне не сильно интересно что в кишках, пока оно решает мои задачи. что до качества кода — да, оно не везде высокое.

@LittleChris, Диагноз по тому простому факту, что если тебя поджимают сроки, то свой инструментарий ты должен давно уметь. То есть ситуация "завтра дедлайн, а мне надо прочитать тонны манов" — невозможна. //К.О.

@Kim, это был не «мой инструментарий». это «инструментарий, которым приказал пользоваться заказчик (потому что он оплатил пару приватных реп в гитхабе) и который выбирал не я».
А ситуация была «доработать и внедрить workflow сегодня, а лучше вчера». учитывая тот факт, что мой стаж работы с git составлял пару месяцев и 5 команд из туториала на гитхабе, а git был и моложе на пару лет, и ещё большее говно, чем сейчас, задача была практически невыполнима вовремя. Следующий (и все последующие) проект я положил под mercurial и не пожалел об этом ни разу за все полтора года, которые я с ним работал.

@Sectoid, Прочитай любой срач hg vs git на лоре :)

@Sectoid, надо понимать, вам не составит труда переписать github.com так, чтобы оно использовало эти самые низкоуровневые команды?

@Sectoid, кроме того, у git отсутствуют extension points. задача «добавить ключ к произвольной команде» или «пищать в спикер каждый третий вызов любой команды» не решается средствами git api, а решается (пере)определением алиаса в шелле (см. git achievements сотоварищи).

@Sectoid, Если вам нужно менять историю — вы что-то делаете не так.

@Sectoid, А если кому-то для работы хватает svn, и он, используя git, знает и использует его в этом объёме, то он плохой работник?

@asphyx, почему?

@asphyx, на минуточку, таких юзеров git — что-то ~70%

@Sectoid, и вот здесь вопрос.
Зачем тратить ресурсы на «изучать модель», если пользуясь нормальными DVCS (veracity, hg, bzr) этого делать не нужно?

@LittleChris, LOL, bazaar занесли в нормальные dvcs

@dr-Chaos, ложь чуть более чем полностью. Начинается это с того что она тащит с собой пол cygwin-а, perl, vim и еще кучу ненужного говна. В инсталлере msysgit или как там его куча каких-то странных опций вроде работы с EOL, каки-то идиотские git shell-ы, и т.д. И заканчивая тем что какой-нибудь невозможностью откатить все измененные файлы. Частично в таком случае помогает создание staging area и удаление её тут-же, но не всегда.

@Sectoid, по теме — в git-е отсутствует нормальная поддержка pull/push по HTTP. В корпоративной среде это очень важно. Сам был свидетелям попыток это завести с целью избежать еще одного открытого порта не сервере.

@dion, ЕЩЁ ОДИН ОТКРЫТЫЫЙ ПОРТ НА СЕРВЕРЕ!!!1111

@Sectoid, Не передергивай. Цель работы — код. Ты можешь сказать по коду, какая vcs была заюзана?

@LittleChris, И что?

@dion, ORLY? а как я пушу по http? O+o

@Sectoid, сэр, вы адекватны? что значит "изучать программирование" в твоем смысле?

@LittleChris, "нормальность" модели субьективно — в сад.

@asphyx, я этого и не утверждал. это значит что у него другой инструмент) ну и отсубятина: "морковки слаще не едал", видимо

@overmind88, в сраче много шума. правда в результате эта тему к нему и скатилась, увы(

@LittleChris, посмотрел пример — принципиальной сложности не вижу. на bash подойдет?)

@Sectoid, я не говорил что оно не работает. Оно работает но через одно место. И судя по мануалу progit.org ничего и не поменялось...
Если два отсутствующие локально коммита на сервере уже зажевало в pack файл, то сливаться будет он весь... А если repack-а давно не было то при pull-е будет огромная куча GET-запросов.. Сюда же добавить что репозитории для этого дела нужно заводить с отдельными ключами плюс заниматься непонятно каким извращением с WebDAV-ом. А так да, вроде и работает.

@overmind88, дада, мы уже выяснили, что чтобы быть нормальной, название vcs должно начинаться с «git».

@Sectoid, на сишечке, будьте любезны

@Sectoid, впрочем, если сможете хранить репозиторий в реляционной БД (sqlite например, но подойдёт любая) — пишите хоть на баше, хоть на брейнфаке

@balodja, git commit -a

@ComradeDOS, github.com
hg convert . .git/hgcheckout
hg -R .git/hgcheckout push $HG_REPOВ отличие от этой поделки, hg-git не использует /usr/bin/git. Вообще.

@LittleChris, Зря. Если бы использовал, то работал бы быстрее и потреблял меньше памяти. ;)

@Sectoid, Как я понял авторы что на <jhw.dreamwidth.org>, что на <jhw.dreamwidth.org> жалуются на то, что mercurial в истории сохраняет имена веток, а git хранит имена только для текущих бранчей. Из-за этого (смотри вторую ссылку, там проще расписано) нельзя понять какая ветка истории всегда принадлежала ветке release, а значит нельзя, например, удобно разобрать какие изменения пришли извне твоей линии разработки и которые надо будет, соответственно, описать в обзоре перед релизом.

@Sectoid, И да. Реквестирую по результатам сводную табличку

@Sectoid, git-svn не юзал, с cr/lf всё ок — настраивается хоть поплатформенно, хоть по типам файлов. Со скоростью всё нормально, отличий сильных не наблюдается.

@dion, Не понятно как нормально работать ему мешает пол cygwin-а и прочее? Ну валяется себе и есть не просит. Про откатить файлы — не понял о чём именно речь.

@dion, Не, ну господа. Больше года назад в git-е появился CGI, который нормально работает не с файлами, а с объектами репозитория (git-http-backend). С WebDAV с тех же пор возиться не надо, т.к. аутентификация будет та что укажешь веб серверу. Ну и под винду уже месяца 3 как можно negotiate аутентификацию использовать, т.к. curl виндовый допилили, до этого ntlm приходилось юзать.

@dr-Chaos, это и есть костыли. А мешают много чем. Например непонятно зачем в системе второй перл, vim и еще кучу говна... Про откатить файлы — я не раз сталкивался с тем что даже после reset --hard, git status показывает что есть modified файлы

@dion,
непонятно зачем в системе второй перл, vim и еще кучу говнаwindows way. вы же хотели чтобы каждая программа приносила с собой всё что ей нужно и не докучала зависимостями.

@dion,

Например непонятно зачем в системе второй перл, vim и еще кучу говна...
А hg использует петон, установленный в системе?

@max630, зачем git-у vim?

@overmind88, можно и так.. на оффициальном сайте можно выбрать либо в виде одного exe-ника (созданного py2exe) либо чтобы был нужен пистон.

@dion, я полагаю редактировать commit message

@max630, а если я вместо вима пользуюсь notepad.exe?

@Sectoid, зырить диффы удобнее нормальной UI-ной тулзой..

@Sectoid, вот же некропостеры...

@Sectoid, SVN этого никому не нужного говна с собой не тащит

@dr-Chaos, тормоза в винде ощущаются когда начинаешь работать с толстенным репом. а git-svn, увы, был ОЧЕНЬ нужен, т.к. на git полностью ушли далеко не сразу.

@dion, SVN это компенсирует тем, что сам является говном)

@Sectoid, это говно хотя бы нормально юникод умеет. В отличие от вашего stupid content tracker-а

@dion, щито?

@Sectoid, положи в linux в репозиторий файл с кириллицей в имени.. И потом склонируй его на венду.. Или даже на тот же linux только с другой локалью.. А потом сделай аналогичные действия с SVN-ном

@Sectoid, Толстенный это в цифрах — это сколько? У нас он вроде тоже не маленький.

@Sectoid, немного оффтоп, но думаю, пригодится: сводная табличко «фатальных недостатков» Git и Mercurial — blog.develop7.info