Чтобы добавлять сообщения и комментарии, .

@killy:
killy

Наткнулся на Git from the inside out (текст), понравилось.

Стало интересно, что происходит внутри при более сложных вещах — при редактировании истории. На ютубе есть ещё доклады, затрагивающие внутреннее устройство Гита, но они не идут сильно дальше этого.

Также захотелось увидеть что-то подобное про Mercurial. Видео не нашёл, и в процессе поиска вспомнил, что Меркуриал не задуман так, чтобы выставлять детали имплементации. Но если очень хочется, то официальная wiki — это наиболее содержательный источник информации. Начать удобнее всего оказалось с Mercurial for Git users и далее следовать по ссылкам на термины. В разделе Developer Info — Internals оказалось не густо.

На SO упоминаются статьи Behind the scenes и Towards a Better SCM: Revlog and Mercurial (гуглибельно, я не знаю нормальной ссылки), но они не слишком содержательны, по крайней мере на том уровне, на котором я хотел удовлетворить своё любопытство.

Одна деталь:
Аналогом команды git cat-file для просмотра внутренних бинарных файлов в Mercurial является подмножество команд hg debug*. Полный список дебажных команд удобнее получить через hg help debug.

@L29Ah:
L29Ah

Что нажать чтобы git↔hg?

@segfault:
segfault

Я ведь правильно понял, что bookmarks в hg это ветки в git (причем, закладки в hg — локальные, их можно залить на удаленный репозиторий, но только в справочных целях, или хз) , теги — это теги, а ветки в hg — это вообще нёх. Каждый коммит типа помечается именем ветки, в результате ветка — это кусок графа коммитов, который может иметь несколько висячих голов, и есть специальные коммиты для "закрывания голов". Я представляю как это придумывалось, типа чтобы не терять код и не путаться в топологии веток, что от чего пошло, но вот у меня ветка с кучей голов, и что мне с ними делать? В гите эти головы будут просто именованными ветками, удалил ветку — "закрыл голову", а в hg и закладки не являются полноценными ветками, и ветки овердезайнутый кал.
Я всё верно понял?

@max630:
max630

pastebin.com вот поэтому и нельзя

а, да, и индекс не нужен же, зачем он

@k0st1x:
k0st1x

от opennet вышел на гугл-группу по mercurial,
там видно, что facebook пилят mercurial-сервер на Rust,
а Mercurial 4 будет наконец то работать на python3
groups.google.com

да и вообще на bitbucket оказывается есть публиные репы facebook, где они развивают hg
bitbucket.org

@Balancer:
Balancer

Блин, как меня достало каждый раз при заведении сложного репозитория ломать голову, Git@GitHub или Mercurial@Bitbucket. На первом коммьюнити и внешние инструменты. На втором — беспроблемная работа. Ну не осиливаю я логику Git. 60+ репозиториев на GitHub и каждый день(!) приходится ломать голову, как победить очередные проблемы с коммитами. В то время, как в Mercurial всё просто молча работает не вызывая проблем... Это уже даже не карма какая-то, это идеологическая несовместимость, видимо :) Что делать, блин...

@max630:
max630

смотрите чего гугль заебашил bitbucket.org будут пропихивать в апстрим

@OCTAGRAM:
OCTAGRAM

Пытаюсь понять, как держать актуальную версию. В hg я делаю pull, потом update, и я знаю, что update по умолчанию либо обновит, либо пожалуется, что у меня закралась пакость в этом каталоге, и я при необходимость могу сломать эту пакость через колено, сделав принудительное обновление, и у меня будет свежая версия из репозитория. Про git в Интернете пишут, что git pull = git fetch && git merge, но я не хочу merge. Если у меня что–то поменялось, я не хочу это сливать, а хочу свежую версию из репозитория. Не понимаю. Может, надо было через hg-git работать и не мучиться с этим непонятным git.

@Balancer:
Balancer

добавлено 4102 наборов изменений с 4724 изменениями в 1256 файлах
Нормальное обновление :)

@Zert:
Zert

С удивлением узнал, что Go уже переехал с меркуриала на гит: golang.org
Вот это зрада так зрада. На меркуриале теперь что, вообще не осталось никаких значимых проектов?

@OCTAGRAM:
OCTAGRAM

JScript не поддерживает UTF-8 с BOM. UTF-8 без BOM выдаёт ерунду в выводе консоли. ANSI/OEM не хочу. UTF-16LE с BOM определился и работает нормально, но теперь TortoiseHg считает файл двоичным.

@Zert:
Zert

Ртутекапец mercurial-scm.org

@max630:
max630

а есть какое-нибудь актуальная документация этого вашего hg evolve? Мне что-то только какие-то допотопные вики и блогпосты попадаются, которые ещё советуют екстеншен как не встроенный подключать и в которых картинки протухли.
И сразу уточнение — если верить evolution.experimentalworks.net , оно не отменяет всю эту ебанину с фазами, и чтобы обмениваться ребезящейся веткой надо заводить специальный репозиторий с publishing=false. Я правильно понял?

@Zert:
Zert

Что заставляет людей пользоваться этим убогим тормозным поделием? Какого хрена оно так долго качает?

@Balancer:
Balancer

О! Нашёл, наконец, работающий вариант двухсторонней синхронизации git <-> mercurial.

github.com

@khades:
khades

mercurial <3

@Zert:
Zert

А вы ещё спрашиваете, почему я меркуриал обсираю: metaclass.livejournal.com
Повторил описанную ситуацию с гитом (используя touch -r, чтобы время модификации сохранить), не повторилась. С меркуриалом повторил без проблем.

@Zert:
Zert

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

@Zert:
Zert

Почему эта сифа не пишет прогресс при клоне?

@segfault:
segfault

github.com
До маджита как до китая раком, но основная функциональность работает.

@webus:
webus

рванул с git обратно на hg. все же mercurial/hg удобнее в разы.

@provaton:
provaton

Жаль, что меркуриал медленно помирает. Мне он всегда нравился гораздо больше гита. linux.org.ru

@Balancer:
Balancer

Есть тут спецы по git и его апологеты-холиворщики? Как вернуть данные и что с ними произошло? :) — linux.org.ru

@AlexVK:
AlexVK

Hg стал изрядно тормозить на проекте в момент клонирования репозитория.

@Balancer:
Balancer

Кажется, есть шанс счастливо разрешить вопрос Mercurial vs Git :)

Опять же, за последние пару лет hg-git вылизали и он больше не вешается на моих репозиториях, а работает шустро, как и «родной» Git. Версии коммитов, правда, в Git'е оказываются другими, но это не так страшно, пока работаешь в одиночку.

Правда, как-то непонятно в статистике, пишет, что коммитов только 11 в master и 11 в другие бранчи, хотя на самом деле у меня только один master и коммитов тысячи. Но в целом — работает. Можно из привычного Mercurial работать с Git-репозиториями :)

Правда, на одном пушится почему-то только с --force. Ругается, типа: «прервано: pushing refs/heads/master overwrites 04265dac2ea2»

@Balancer:
Balancer

Прошёлся по современному состоянию серверов приложений, PaaS и прочему. Года два назад щупал, но не впечатлило ни разу. Потом следил только краем уха в теории. Сейчас полез — офигенно :) Выдают на халяву сразу виртуальные машины, готовые решения, порой, с полноценной ОС в виртуалке. OpenShift поюзал — интересно.

Надо будет по приколу привести свой фреймворк к варианту, легко разворачиваемому и в виде docker-образа, и на том же OpenShift.

И, похоже, судьба мне переезжать на GitHub :-/ Очень много сервисов, работающих с GitHub и git, но не работающих с Bitbucket и Mercurial. А жаль, мне Mercurial намного больше нравится :)
~~~

@segfault:
segfault

А что, мне вот никак-никак нельзя исправить публичную ревизию?

@segfault:
segfault

проталкиваем в ...
поиск изменений
отдалённо: adding changesets
отдалённо: adding manifests
отдалённо: adding file changes
..........

ПРОТАЛКИВАЕМ ОТДАЛЕННО

@max630:
max630

Вообще "зачем сохранять промежуточные версии" — вопрос нериторический. cvs — а её проприетарные аналоги ещё продаются за дикие бабки, и немалая доля тех кто принимает решения и обучает в вузах умеет только в них — в общем случае не гарантировала даже что ты сможешь счекаутить и собрать какую-то прошлую версию. Учитывая что писать внятные сообщения к коммитам они тоже не умеют и не учат — остаётся только функция "найти виноватого". Что, действительно, не так уж и ценно.

@Strephil:
Strephil

О системах контроля версий, почему их тут не используют:
«Если есть задача, если она поставлена, то программа либо с ней справляется, либо нет, третьего не дано.
Программа не может рабоать "лучше" или "хуже".
Либо она РАБОТАЕТ, либо она НЕ РАБОТАЕТ.
Поэтому, если есть рабочая версия, то разработка на этом закончена, это релиз. А если программа не дописана, тогда зачем сохранять промежуточные версии?»

И этот мудак еще преподаёт в ВУЗе.

@Tishka17:
Tishka17

кажется, придётся на время вернуться к системе контроля версий под названием tar

@segfault:
segfault

Однако, аргументы в пользу hg начинают подкупать, вот хочу я посмотреть коммиты сделанные в ветке, а не могу, ибо узнать, где началась ветка невозможно, особенно после того, как ее слили в мастер. А вот в hg коммиты помечаются именем ветки (или уникальным id ветки?), поэтому там это не проблема, в теории.

@datacompboy:
datacompboy

Господа! Кто пользует hg push github — какого лешего там мастер не обновляется на текущее положение?! O_O

@datacompboy:
datacompboy

А есть аналог tig'а для мерка?

@max630:
max630

mercurial: subversion done right: paulhammant.com

@provaton:
provaton

Что-то совсем бедненькие релиз нотесы у любимой системы контроля версий пошли mercurial.selenic.com

@Zert:
Zert

Шах и мат, git: code.facebook.com