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

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

ну да

git daemon

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

Давно.

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

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

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

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

git hooks

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

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

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

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

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

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

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

принимается.

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

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

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

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

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

$ locate -b libgit | wc -l
0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

зачем git-у vim?

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

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

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

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

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

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

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

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

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

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

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

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

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

git rebase -i HEAD~3

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

Ы?

git commit -a

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

git reset --soft ID && git commit --amend

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

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

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

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

commit --amend

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

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

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

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

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

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

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

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

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

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

а не надо так делать.

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

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

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

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

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

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

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

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

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

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

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

почему?

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

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

конкретику в тред

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

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

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

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

Нахуй пошел.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И что?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

щито?

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

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