Дебианизм оперденей головного мозга

[metaclass]

Как известно, ребе theiced постоянно критикует меня за использование разнообразного софта, который по его мнению, написан криворукими уродами, как то - дебиан, дельфи, винда xp, firefox итд итп. Ну, он всегда критикует, это привычно.

Но после того, как я осилил рисование плат в Eagle, который по юзабилити упорот где-то на уровне среднем между "опердень на кларионе под windows95 написанная руССкими программистами методом портирования опердени под DOS" и "клиент-банк, который писали программисты налоговой инспекции, после того как их уволили из НИИГиТ", я начинаю сомневаться в собственной адекватности, может я действительно от 15 летней работы с чужими и своими оперденями сошел с ума и теперь могу пользоваться только софтом, который пишут невменяемые люди и который требует для работы стояния на ушах.

Comments

[gds.livejournal.com]

"тот же хеш" -- мило, это и надо.

git -- понимаю, очень общую схему сделали (content tracker или как там), оттуда и неочевидности. Везде такое: сделаешь подробный апи -- оказывается усложнённым, сделаешь простой -- окажется недостаточным.

bitbucket -- хрен его знает, я пользуюсь, ибо репку дают, вебморда есть, какие-то около-социальные движухи есть (фолловить человека/репку например), а больше мне и не надо.

про имя бранча -- есть такое, факт. А в гите разве не удалением истории делается rebase? Одни changeset'ы удаляются, другие добавляются. Всё равно, по логике, должно оказаться так, что те, кто уже клонировал репку, будут видеть changeset'ы, которые потом удалили, заменив на новые. Хотя тут не уверен, интересно реальное положение дел.

про хранение тегов внутри репозитория -- интересно, чем это опасно? В большинстве меркуриаловских репок, где мне надо было хранить версии, я именно через теги всё решал (история там была принципиально линейная), и не ясно, как можно сделать ногам неприятно. (там, где более сложный цикл разработки, named branches использовать начал, буквально недели назад, однако уже знаю, что их можно закрыть при желании.)

собственно, я понял, как сделать из меркуриала то, что называется "удобная dvcs" (и как её сделать из гита -- тоже примерно понятно, но практики мало), и интересно было, как hg-git работает, чтобы не держать в голове в два раза больше интерфейсов командной строки утилит, работающих с dvcs. Теперь понял, благодарю за ответ. Однако я поднял ещё вопросы, и "я хочу поговорить об этом" :]

[x-den.livejournal.com]

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

1. корявые бранчи: vasia_pupkin и john_doe, имеющие свои "локальные" копии репозитория operden не могут без последующих плясок с бубном иметь бранчи с одинаковыми именами.
2. среди "мейнстримных" OSS-проектов большинство на git, т.е. по дефолту github имеет большую аудиторию и больше подходит для social coding.
3. меркуриал не умеет трекать множественные remote-repositories. т.е. в гит можно сделать remote update и потом в gui-морде поглядеть, что нового в vasia/master, john/master и что jim сделал новые бранчи jim/fix_a и jim/add_b

проблемы с именованными бранчами я описал тут (http://metaclass.livejournal.com/606819.html?thread=9107043#t9107043). букмарки, в принципе, решают их все.

а rebase меняет историю и там, и там. поэтому его и не рекомендуется делать в published репозиториях: удаленные ревизии кто-то может запушить обратно. только в меркуриале это сделать проще, т.к. hg push по умолчанию засылает все отсутствующие коммиты (включая таковые из удаленного бранча), а git - только из активного бранча.

про теги в репозитории: коротко, в разных бранчах один и тот же тег может ссылаться на разные ревизии. то есть возможна ситуация, когда 'hg update some_tag' из бранча A и из бранча Б апнет в разные ревизии. длинно - написано тут (http://mercurial.selenic.com/wiki/Tag#How_do_tags_work_with_multiple_heads.3F). этого можно избежать достаточно простыми гайдлайнами по расстановке тэгов, но возможность выстрелить в ногу останется.

[gds.livejournal.com]

про bitbucket:
2 -- github -- это всего лишь сайт. Я на него захожу раз в четыре недели. Social coding -- видимо не для меня, потому что не предлагают, ибо говно пишу. Но это не относится к hg/git.
3 -- у меня в $repo/.hg/hgrc часто (по надобности) описаны

[paths]
repo1 = ssh://gds@superserver.local/repo/superproject
repo2 = ssh://gds@very.super.server.global/repo/superproject
repo3 = https://hg@bitbucket.org/gds/projectname

про отсылку веток, "git - только из активного бранча" -- интересно, не знал. Ну и остальное прочитал. Полезно, благодарю.

[x-den.livejournal.com]

@git push: от черт, я соврал :) если сделать git push без аргументов, то он запушит коммиты не из активного бранча, а из всех бранчей, существующих и локально, и удаленно.

@paths: имхо, это самый адекватный вариант, что может предложить меркуриал. только отсутствие remote-бранчей вида repo1/master, repo2/master делает эти адреса не более чем алиасами.

@github: опять-таки, имхо, там дело не столько в общении (social as in socialize), сколько в прозрачном превращении "программирования для себя" в "программирование для людей".

[gds.livejournal.com]

remote branches есть, но по полному урлу:

$ hg ident ssh://gds@хост//repo/проект#dev
cca2a487ea50

$ hg ident ssh://gds@хост//repo/проект#default
c64695112b90

Остался один маленький шаг -- понимание "короткийпуть#rev" так же, как "полныйпуть#rev", но никаких теоретических проблем тут нет.

Про github -- согласен, он полезен этим.