Google Go меняет систему контроля версий с Mercurial на Git

Никакие языки больше впринципе не нужны. После того как майкросовт открыла .net. Ядро к версии 3.19 перепишут на c#

Жир потек... толсто!

На самом деле, гит не такое уж говно. Архитектура у него вполне здравая, только интерфейс наркоманский. git pull, который зачем-то делает merge, git reset, который делает 10 разных вещей в зависимости от опций, git checkout, который делает то же, что git reset, но по-другому. Ещё staging area, встроенная в базовую систему команд - явная дурость. Ещё всякая дичь вроде detached head - чтоб Линус вот так же однажды проснулся, а голова в тумбочке... Так, о чём это я. Если сделать гиту альтернативный интерфейс, хотя бы в стиле hg, получилась бы отличная система. Почему до сих пор никто этого не сделал? Не верю, что весь мир населён только наркоманами, марсианами и Линусом. Может займёмся?

TortoiseHg, принципиально РАЗНЫЕ программы

Не поможет.

Опередил!

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

потому что для норкоманов есть hg

ну хз, помоему, ты утрируешь

В данном случае (хотя выше по теме утрирование было) — нет. Git, действительно, позволяет слишком вольно переписывать историю. А мне, наоборот, нужно как можно более надёжное её сохранение, что присутствует в Mercurial.

Пользоваться удобнее гитом, а не хг

Вот это уже вопрос исключительно привычки. Мне намного удобнее Mercurial. Но тут я, как раз, обобщающих заявлений не делаю :) Кому-то и Git удобнее.

Историю у нас главном сервере редактировать запрещено

А если потребуется? Фишка в том, что в Git придётся запрещать push -f явно и на сервере — а на каком? У нас же по сути — DVCS. Начнёшь пушить на «главный сервер» без -f, на свою другую машину — с «-f». Как потом всю эту кашу сводить?

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

Тебя же самого остановило пользование гитом именно предпочтение hg)

Нет. Я, как раз, планировал переезд на Git, хоть он мне и менее удобен. Но в процессе освоения быстро (и хорошо, что рано) столкнулся с такой его гибкостью в отношении истории, которой я стараюсь избегать куда больше, чем неудобств :)

И, да, если что, у меня на GitHub 16 репозиториев :) Так что нельзя сказать, что у меня баттхёрт, идиосинкразия или предельный случай неосиляторства :) ...

Что git-овские ветки позволяют сделать такого, чего не позволяют mercurial-овские?

их можно редактировать, удалять, создавать заново из других предков, и т.п. и не надо втирать про всякое mq и strip. удалить бренч с hg-сервера может только админ посредством ssh на сервер. и то через какой-то анал. а если бранч пушнуть — то и локальный так просто не удалишь.

Кстати, есть ли в git аналоги revsets и evolve

да, искоробочно причем.

Как потом всю эту кашу сводить?

man git-merge

Так что нельзя сказать, что у меня баттхёрт, идиосинкразия или предельный случай неосиляторства :) ...

увы, должен тебя разочаровать...

И хорошо. Уже надоело, что проекты уже перенесли репозиторий на гитхаб/битбакет/куда-угодно, а багтрекер всё равно на гуглокоде. И таких проектов много.

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

Если б я хотел написать сравнение - я бы оформил статью. С гитом я работаю с 2009 года, с hg - с 2011. Сейчас hg основной на работе. Каждый раз, когда пользуюсь git - понимаю, насколько тяжело с hg. Работаю преимущественно в консоли.

все точь в точь как у меня. после git, hg кажется каким-то svn на стероидах (или, как говорит мой коллега, svn на питоне).

ток я git юзаю чуть дольше, практически с его появления, а hg всего полтора года (но на фуллтайм-работе)

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

hg help bookmarks

да, искоробочно причем.

враньё. revsets >> gitrevisions; evolve отсутствует

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

Ну то есть, всё то, чего пользователи hg намеренно избегают.

Неправославно. Названия комитов на русском)

Если сделать гиту альтернативный интерфейс, хотя бы в стиле hg, получилась бы отличная система.

man hg-git.

На самом деле, они просто хотят pull request'ы. А гуглкод, насколько я знаю, в них не умеет.

hg help bookmarks

ты сам-то пробовал этим пользоваться? это просто именованные heads. ничего общего с нормальными git branches. хотя адепты hg так и не считают.

более того, как это поможет, если все остальные коллеги по работе используют hg branch, и этих бренчей тыщи, и знать про эти букмарки они не хотят?

да и я чето не понял в чем профит от них.

evolve отсутствует

чего это? судя по докам, git rebase все это умеет. но может я что-то пропустил.

Ну то есть, всё то, чего пользователи hg намеренно избегают.

как можно избегать того, чего нет?

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

Они упоролись шило на мыло менять.

GCode на GH — это шило на зингер. Так что можно только порадоваться за разработчиков.

не нужен. гугл еще ничего хорошего не родил

Названия комитов на русском

Я в одно рыло пишу, так что это чисто для себя пометки :)

Сам-то пробовал?

В разработке — нет. А там что-то не работает?

Где в гите аналог evolve? Где в гите аналог phases? Где в гите гарантия иммутабельности истории на сервере?

Ах да, если этого нет в гите, то оно ненужно.

uncommit

если я правильно понял, что делает эта команда, то в git этого можно достичь комбинацией checkout/reset/rebase, но может есть специализированная команда (мне не приходилось такое делать).

prune, touch, gdown, gup

все это умеет git rebase.

evolve
automatically resolves troubles affecting changeset

хз что эта команда делает, так что не могу с уверенностью сказать, есть ли такое в git.

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

Гугле публично закопало своё гуглекоде.

Где в гите аналог phases?

судя по описанию, аналог phases - это git push без -f :)

А если потребуется? Фишка в том, что в Git придётся запрещать push -f явно и на сервере — а на каком? У нас же по сути — DVCS. Начнёшь пушить на «главный сервер» без -f, на свою другую машину — с «-f». Как потом всю эту кашу сводить?

Если потребуется - это будет делаться с тимлидом рядом на стульях, если это хоть чуть не тривиально.

DVCS мешает наличию главного сервера, откуда собираются релизы, берет задачи билдсервер и клонируют разработчики? Нет, не мешает.

Зачем использовать -f ? Это единичные случаи, что за дикость, корежить репозитарий? В отличие от hg, гитовые ветки намного гибче и незаметней, не нужно ничего курочить. Не могу объяснить, это чувствуешь, когда используешь и то и другое. Но -f - это хак. Хаки в воркфлоу не входят, как бы не хотели этого критики. Даже rebase не входит.

судя по описанию, аналог phases - это git push без -f :)

Нет, phases - это отслеживание того, какие изменения уже были опубликованы, а какие ещё можно редактировать.

Гит овцы на редактировании истории все помешаны, при этом у них даже такого простого предохранителя нет. Слабоумие и отвага.

Даже rebase не входит.

это у кого как. у нас даже на работе в hg, rebase вместо merge рекомендованный воркфлоу, там где это имеет смысл.

Вы все придумываете, потому что в гите этому не нужно придумывать имена. Плагинная концепция сгубила hg. Все плагины - костыли, которые не были продуманны архитекторно в ядре hg. В гите все это есть, органично и тривиально, если привыкнуть к нему, он продолжение пальцев, как emacs (или vim).

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

Ну так покажи нам расширение для гита, которое предоставляет аналог evolve?

Гит овцы на редактировании истории все помешаны, при этом у них даже такого простого предохранителя нет. Слабоумие и отвага.

man reflog

ты больной? это встроенные фичи гита все. причем фундаментальные. какие нах еще расширения?

мы в hg используем rebase, в гите нет.

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

я в гите rebase постоянно использую (опять же, там где это необходимо). не вижу, зачем не использовать.

Где в гите аналог evolve? Где в гите аналог phases? Где в гите гарантия иммутабельности истории на сервере?

Про весь этот борщевизм знает не больше 1% пользователей ртути. И в реальной жизни последствия от push -f легко восстанавливаются, плюс не надо запоминать кучу новых команд для манипулирования графом. Эти люди еще пытаются рассказать про сложность cli интерфейса гита, пффф.

P.S. Я бы не отказался от фаз в гите, да.

это, видимо, вопрос вкуса и привычки

Все плагины - костыли, которые не были продуманны архитекторно в ядре hg.

ага, а архитектурно там внутри какое-то подобие то ли svn, то ли cvs, то ли их помеси. во всяком случае, у меня такое впечатление создалось при курении их девелоперских доков.

что конкретно она делает. из документации я не распарсил.

Она позволяет пометить коммиты, чтобы после переписывания истории и потери ссылок на них, они все же остались в графе.

это, видимо, вопрос вкуса и привычки

это желание не срать в историю мерж-коммитами.

Она позволяет пометить коммиты, чтобы после переписывания истории и потери ссылок на них, они все же остались в графе.

ага, т.е. дефолтное поведение гита. спасиб за инфу.

это, видимо, вопрос вкуса и привычки

Это вопрос безотчетного страха перед зловещими словами «переписывание истории».

man hg-git

Я пробовал начать его использовать для поддержания копии основных реп на GitHub'е. Но запарился — постоянно лезут глюки. Вот прямо сейчас, для иллюстрации:
[code]
hg push git+ssh://git@github.com:Balancer/bors-core.git
проталкиваем в git+ssh://git@github.com:Balancer/bors-core.git
[«git-receive-pack 'Balancer/bors-core.git'»]
поиск изменений
adding objects
прервано: git remote error: refs/heads/2eafc6248f5bf15b183e230e14396f3ea50c5d96, refs/heads/master failed to update
[/code]

Это после предыдущего успешного коммита через git. Идём длинным путём. Сперва создаём пустой git-репозиторий, пушим через наш hg-git туда, а уже из него через пресловутый --forcе (всё равно терять нечего) пушим на GitHub. Всё проходит отлично. Всё через git коммитится/пушится нормально (сейчас не проверял, но проверял раньше не раз). Но стоит повторить попытку сделать hg push git... — опять ошибка рассогласования refs/heads/master.

Я бы тупо прописал -f для hg, всё равно терять на git нечего, но оно для hg git не работает :)

...

А так — был бы неплохой компромиссный вариант... Хранить у себя основное в Mercurial, а результат раздавать в GitHub (благо «социальная сеть»).

...

Вот, привёл сейчас на GitHub репо https://github.com/Balancer/bors-core в соответствие репе Mercurial на https://bitbucket.org/Balancer/bors-core . Если интересно кому-то, кто в этой кухне разбирается, можно попытаться попробовать понять, что не так с вариантом hg git.

Может, hg-git тупит на таких танцах с ревизиями? — https://bitbucket.org/Balancer/bors-core/commits/all

Если потребуется

А вот у меня другие взгляды на этот вопрос. Так что — вопрос идеологии. Вам больше подходит идеология Git, мне — Mercurial. Но я же не переубеждаю Вас, а Вы почему-то хотите переубедить меня :)

Там настолько много всего не работает, что убиться проще. Постоянно рушится с ошибками типа «abort: 00changelog.i@c4ac49ffed33: no node!» или «abort: unknown revision '665ba15ea4b529cb1a9e3a7af0c15ec6b6fcb61d'». Например, если удалить ревизию с помощью strip, а потом сделать pull. Это такая частая проблема, что даже сделали костылик hg git-cleanup на этот случай. Только помогает он через раз. При этом push/pull ещё и тормозит. Ещё в .gitignore не подерживаются !исключения - хоть и дебилизм, но многие проекты ими пользуются, и когда у тебя игнорятся файлы, которые игнориться не должны, это сильно портит нервы. Зачем вообще так жить?