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

Краем глаза глянул в темку. Вот что пришло на ум.

1) Опцией --force следует пользоваться только тогда, когда точно понимаешь что после нее произойдет. Если не уверен всегда стоит сделать локальный пример и попробовать.

2) У гит и меркуриал два разных подхода в работе с репозиториями. Не зная их ни у первого, ни у второго не стоит ими пользоваться. Иначе обязательно что-то сломаешь.

3) Не стоит ждать, что гит будет работать как меркуриал, или меркуриал как гит.

И еще мне не ясно, почему нельзя было слить две репы на диск и локально попробовать поиграться. Мы далеко не всегда все знаем, и что-то можем упустить. Между тем вижу необдуманное использование команды, результат от которой ожидался другой. Сразу вспоминается правило хорошего тона работы с файлами(). Всегда должен быть исходный файл(в нашем случае репозитарий) из которого можно восстановиться. Если он уже не нужен, всегда можно удалить его.

Ок, про js аргумент принимаю.

Потому-что по функционалу она не дотягивает до линукса

На x86 думаю что дотягивает. Я много раз вёл дискуссии с вендо-админами, у них всё работает. Вопрос только какой ценой. Вот ты можешь назвать задачу которую нельзя сделать на венде? Там, если что, тоже шелл есть. И даже, о ужас, до сих пор пишут bat-файлы.

Вот ты можешь назвать задачу которую нельзя сделать на венде?

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

Вот объясните мне логику Торвальдса:

git log --decorate - вывести имена ссылок для каждого комита.

decorate - украшать, отделывать. Почему, ***ть, украшать? Почему не git log --ref-names? )

Каждая уважающая себя IT-контора считает себя обязанной создать свою копию свободного продукта. Будь то дистрибутив Linux, браузер на базе хромиум или язык программирования. Только толку от этого?

Зачем тебе нужно закомитить изменения в файле в 2 разных комита? У тебя точно архитектура проекта в порядке если ты занимаешься таким извращением?

Нельзя, затылок. Линус их не принимает.

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

их можно редактировать,

Что такое «редактировать бранч»?

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

Специально для любителей анархии есть bookmarks.

и не надо втирать про всякое mq и strip. удалить бренч с hg-сервера

Судя по упоминанию mq и strip в этом контексте, ты просто чего-то не понял.

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

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

Это не ответ. Давай конкретные команды. Особенно интересует аналог revsets.

А дополнительное изучение хипстерского Hg

Дурик. Mercurial - vcs, а не патч-генератор. Diffutils везде один и тот же. И если девелоперу влом изучить 2-3 команды смены состояния исходников, читай «промотаться назад»,«промотаться вперед» и сделать патч между двумя состояниями и отправить в мэйллист - вжопу такого разработчика и в прямом и переносном. И называть пользователей 3

... и называть пользователей меркуриала хипсторами только из-за разницы в несколько команд - себя не уважать.

WTF? Почему эта базовая функциональность недоступна «из коробки»?

Столько кирпичей из-за строчки в конфиге.

я должен ставить дополнительно какую-то мокрую письку

Тебе к доктору надо, родной.

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

яних#янепонел.jpg У тебя гит Шредингера? Или все-таки и там и там для пересоздания брачная из предков, сначала надо пройтись по всем этим предкам, иначе на выхлопе получишь невнятную буйню? Объем работы везде один. И это таким как ты руки отрывают за нарушение истории разработки. Что за чем следовало и как развивалось имеет такое же значение как и сами исходники.

так и у golang будет на гитхабе только зеркало, а так gerrit, что само по себе система управления репозиториями. Так что забудьте про pull requests через гитхаб

https://groups.google.com/d/msg/golang-dev/sckirqOWepg/YmyT7dWJiocJ

We will use a Google-hosted instance of Gerrit for code reviews.

Зачем тебе нужно закомитить изменения в файле в 2 разных комита? У тебя точно архитектура проекта в порядке если ты занимаешься таким извращением?

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

Все просто. Уже просматривая изменения перед внесением понял, что лучше их разделить на два.

Что за чем следовало и как развивалось имеет такое же значение как и сами исходники.

Имеет, но только для тех, кто давно работает. А вот тем, кто только что пришел, вообще-то, желательно понизить порог входа. А для этого чем меньше будет овна в ветках, тем лучше.

Тем более, обычно, изначально разработчиков мало. И проинформировать о том, что историю почитили легко.

Да и вопросы патентования обходятся. Кто-то внес код из чужого проекта насрав на права. У тебя в истории он висит доступный любому. Назови выход из положения без правки дерева разработки.

Печально. Hg на голову удобнее, чем Git. Не по своей воле приходится пользоваться Git. Hg как то человечнее чтоли...

И да, история в Hg это эталон как именно должна выглядеть история проекта, а не эти ваши постоянные git rebase...

Поддерживаю на все 100%!

Поддерживаю на все 100%!

Расчет хипстеров окончен.

... и называть пользователей меркуриала хипсторами только из-за разницы в несколько команд - себя не уважать.

Эти несколько команд - как дополнительное измерение.

Хипстеры ползают по плоскости, а у остальных есть еще третее измерение, и те кто хотят могут летать.

Что такое «редактировать бранч»?

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

Специально для любителей анархии есть bookmarks.

как это поможет, если все бренчи в репозитории не являются bookmarks?

Судя по упоминанию mq и strip в этом контексте, ты просто чего-то не понял.

нет, это ты цитируешь как-то поперек.

Это не ответ. Давай конкретные команды. Особенно интересует аналог revsets.

начни с себя, и дай конкретную команду hg revsets, а то непонятно че ты от меня хочешь.

Специально для любителей анархии есть bookmarks.

как это поможет, если все бренчи в репозитории не являются bookmarks?

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

Судя по упоминанию mq и strip в этом контексте, ты просто чего-то не понял.

нет, это ты цитируешь как-то поперек.

Я цитирую то, что ты пишешь.

Давай конкретные команды. Особенно интересует аналог revsets.

начни с себя, и дай конкретную команду hg revsets

Я и начал: Google Go меняет систему контроля версий с Mercurial на Git (комментарий)

Впрочем, вопрос о revsets снимается - с git-revisions всё ясно.

Ну и зачем тогда гугл переходит с Hg?

Откуда мне знать? Там ведь даже многие команды одинаково выглядят.

Аргумент про большую популярность гитхаба выглядит правдоподобнее - им ведь всё равно с гугло-кода переезжать надо.

Кстати, битбакет поддерживает и меркуриал и гит.

Зачем тебе нужно закомитить изменения в файле в 2 разных комита? У тебя точно архитектура проекта в порядке если ты занимаешься таким извращением?

Потому что разбивка изменений в файлах на тематические коммиты, например, после применения патча — базовая функциональность любой VCS.

Столько кирпичей из-за строчки в конфиге.

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

история изменений — вещь неприкосновенная

Поэтому от запланированного переноса своих проектов на Git отказался :)

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

Никак.

и я о том же.

Я цитирую то, что ты пишешь

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

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

Я надеюсь что твои «тематические комиты» не ломают твой проект и вы там в гите не делите целостность комита ради красоты.

а о том чтобы перед отправкой в репозиторий почистить патчи.

+1. в меркуриале в истории всегда адский срач. чтобы с этим бороться - у нас перед мержем в транк создают новый бренч, и в него делают комбинированный коммит со всеми изменениями из feature branch. таким образом, в транк пойдет 1 коммит. после этого админ может удалить feature branch, если его попросить. геморрой на ровном месте.

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

http://www.syntevo.com/smartgit/ take this, hg supported.

после этого админ может удалить feature branch

После чего вы теряете историю этого бренча, может стоит начать бороться со срачем который скрывает этот комбинированный комит?

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

Лучше бы остались на SVN.

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

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

и да, в основном это приходится делать только тем, у кого срач в истории feature-бренчей. есть множество более аккуратных людей, кто (обычно) просто мержит без извратов. особенно мелкие фиксы. но даже если ты супер аккуратный — у тебя все равно за месяц в истории накопится штук 10-20 коммитов которые исправляют опечатки, и подобные вещи. а вышеупомянутые обезьяны даже про amend не знают.

Лучше бы остались на SVN.

лучше бы был гит.

Ну чем им ртуть то неугодила?

Почему такое презрительное отношение к ртути?

Mercurial has served us well, but it's time to move on. The world today is quite different from the world then. Most members of the Go community use Git and host their work on GitHub, and we should join them. Thanks to the efforts of open source projects like Android, we now have access to a Git-based code review system that fits our workflow.

Не видит Rob Pike будущего у Mercurial, что поделать.

Без качественного кроссплатформенного GUI, можете засунуть весь этот большой функционал и хорошую документацию в любое удобное для вас место, скорость туда же. А я буду пользоваться удобным TortoiseHg, доведенным почти до совершенства, хотя простые команды типа push/pull -u я делаю в консоли. Точка.

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

походу у вас народ гуляет пару дней после выходных =) имитируя билды, тесты. потом за четверг делает патч и за пятницу вливает 1 коммит. не то что я не позволяю такое делать, просто делать это системой немного странно. иногда ж надо и версии сдавать =) /Sleepy

Так что щас самое модное для написания безопасного безглючного клиентского js (для нубов)? Я юзал livescript, но это совсем не то, это транслятор который делает дебаг ещё сложнее.

Не понятно при чём тут гит. Пока ты историю не тронешь она не изменитс

При том, что на git это легко сделать машинально. Один «-f» — и история может быть убита.

Кроме того, наверняка речь идёт не о том чтобы задним числом коммиты править, а о том чтобы перед отправкой в репозиторий почистить патчи

Так проблема-то в том, что легко именно старую историю потерять. Вот так начнёшь чистить, что-то перепутаешь, потрёшь в старой, не заметишь, закоммитишь, через год понадобится что-то раскопать... Опаньки.

А если сделать amend на старом коммите, от которого зависят другие то этот комит не починится, а просто создастся новый, я правильно понимаю?

Почему такое презрительное отношение к ртути?

Потому что не GitHub. Не модно. По-моему, единственная причина :)

При том, что на git это легко сделать машинально. Один «-f» — и история может быть убита.

Ты не можешь такие изменения пушить в удалённый репозиторий. Сервер не даст.

Мне кажется, ты не совсем представляешь о чём идёт речь. Старую историю никто не меняет. Переписывают только последние коммиты. И после того как их запушили и их утянул народ ты не можешь ничего сделать. Разве что новый репозиторий создать.

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

Лайвскрипт и кофескрипт - это шило на мыло. В то смысле, что не решают проблем js. Тайпскрипт решает. Его мелкософт, кстати, тоже на гитхаб перевела. И активно развивает. Основной кайф тайпскрипта - репозиторий DefinetiyTyped. В нем лежат описания типов для всех популярных браузерных и nodejs-либ. Подключаешь такое описание - и компилер начинает проверять правильно ли ты либой пользуешься, правильные ли аргументы в методы подаешь.

А через полгода-год гугл должен запилить Angularjs2 на собственной версии тайпскрипта c плюшками - atscript.

Чем Github не GUI? Я лично считаю, что крутые программисты (не win) кодяд в vim, emacs и т.п., а не в GUI.

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

Один «-f» — и история может быть убита.

один случайный rm -rf — и нет проблем.

А SourceTree не пробовали?