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 ()

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

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

makoven ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

hg help bookmarks

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

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

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

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

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

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

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

man hg-git.

quantum-troll ★★★★★ ()
Ответ на: комментарий от xio4

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

quantum-troll ★★★★★ ()
Ответ на: комментарий от littlechris

hg help bookmarks

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

KRoN73 ★★★★★ ()

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

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

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

uncommit

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

prune, touch, gdown, gup

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

evolve
automatically resolves troubles affecting changeset

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

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

waker ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

man reflog

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

bj ()
Ответ на: комментарий от quantum-troll

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.

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

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

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

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

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

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