LINUX.ORG.RU

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

 , , , ,


2

2

Языку Go уже 5 лет, и разработчики решили сменить систему контроля версий с Mercurial на Git.

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

Основной репозиторий проекта Go и все его субрепозитории, а также страничка Wiki и багтрекер вскоре будут размещены на GitHub.

Системой рецензирования кода будет Gerrit.

Процесс миграции должен начаться вскоре после выхода Go 1.4 в начале декабря. А Go 1.5 будет первой версией, размещенной на GitHub.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от KRoN73

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

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

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

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

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

vitalikp ()
Ответ на: комментарий от makoven

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

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

waker ★★★★★ ()

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

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

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

makoven ★★★★★ ()
Последнее исправление: makoven (всего исправлений: 1)

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

man-eater ()
Ответ на: комментарий от EXL

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

bhfq ★★★★★ ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от waker

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

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

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

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

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

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

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от EXL

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от EXL

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от waker

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

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

anonymous ()
Ответ на: комментарий от Pinkbyte

так и у 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.

avsej ()
Ответ на: комментарий от bhfq

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous ()

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

abc ()

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

abc ()
Ответ на: комментарий от abc

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

anonymous ()
Ответ на: комментарий от tailgunner

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

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

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

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

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

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

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

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

waker ★★★★★ ()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от waker

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

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

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

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

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

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

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от EXL

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

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

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

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

DarkEld3r ★★★★★ ()
Ответ на: комментарий от bhfq

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

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

EXL ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

EXL ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от tailgunner

Никак.

и я о том же.

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

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

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

waker ★★★★★ ()
Ответ на: комментарий от EXL

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

bhfq ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

waker ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

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

insider ★★★ ()
Ответ на: комментарий от waker

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

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

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

bhfq ★★★★★ ()
Последнее исправление: bhfq (всего исправлений: 1)
Ответ на: комментарий от bhfq

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

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

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

waker ★★★★★ ()
Последнее исправление: waker (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

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

waker ★★★★★ ()

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

nexfwall ★★★★ ()
Ответ на: комментарий от nexfwall

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, что поделать.

EXL ★★★★★ ()
Ответ на: комментарий от insider

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

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от waker

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

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

anonymous ()
Ответ на: комментарий от makoven

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от waker

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

makoven ★★★★★ ()
Ответ на: комментарий от nexfwall

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

makoven ★★★★★ ()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

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

insider ★★★ ()
Последнее исправление: insider (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

waker ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

waker ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.