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

[metaclass]

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

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

Comments

[x-den.livejournal.com]

hg-git это тот же честный меркуриал, в смысле, расширение для него. то есть локально это будет обычный hg-repo, и магия будет происходить только при общении с удаленным гитом. разработчики клянутся-божатся, что он transparent и consistent, де, коммит запушенный из hg-repo1 в git-master-repo и потом сфетченный в hg-repo2 будет иметь тот же хэш. нюансы с бранчами могут быть, но с тех пор как в hg запилили BookmarksExtension, проблем быть не должно.

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

для наколеночных проектов или in-house development меркуриал лучше, но у него свои тараканы в голове, вроде имени бранча встроенного в метаданные коммита (и, как следствие, не удаляемого без изменения истории) или хранения тэгов в файле внутри того же репозитория (что вместе с бранчами дает возможность выстрелить себе в ногу). впрочем, с расширениями из меркуриала вполне можно сделать человеческий гит.

[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 -- согласен, он полезен этим.

[develop7]

как следствие, не удаляемого без изменения истории

А зачем нужно удалять бранчи?
Кстати, аналогом бранчей в Git являются bookmarkи в Mercurial.

[x-den.livejournal.com]

например, чтобы без головной боли использовать подход branch-per-issue. сейчас нужно либо делать корявые имена, сравнимые иногда по длинне с самим диффом(содержание которых со временем все равно забудется), либо делать бранчи вида fix_operden1, fix_operden2, ... fix_operden100500.

ну и да, букмарки рулят.

[gds.livejournal.com]

кстати про корявые имена -- у гитоводов часто видел различные склонированные репки с такими натужно-выдуманными именами (шаблон действия: "о, надо сделать фичу xxx -- cd .. && git clone mainrepo fix_operden740"), то есть, там тоже приходится фантазировать. С другой стороны, можно и не именовать ветки вообще (но если много или хитро, то нужен glog как минимум, hgk как оптимум).

[kurilka.livejournal.com]

git clone mainrepo fix_operden740
имхо гораздо больше мысли о hg навевает, нафига делать клон если можно просто ветку сделать?

[gds.livejournal.com]

не знаю, при случае спрошу у того гитовода. Но меркуриалом он не пользовался до этого. Может из svn/cvs привычки перешли, хз.

[develop7]

А как нащот обзывать бранчи по имени тикета в багтрекере? Ну и да, --close-branch никто не отменял.

[x-den.livejournal.com]

в общем-то, приходится так и делать, #_short_summary, но это не от хорошей жизни :)

[develop7]

почитал ваш коммент про бранчи выше. согласен.