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 ()
Последнее исправление: maxcom (всего исправлений: 5)

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

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

это как вообще :-/

можешь показать последовательность команд для наглядности?

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

тортойз далеко не совершенен. постоянно слышу матюки коллеги по этому поводу. то зависнет, то криво смержит, то сожрет все 16 гигов RAM.

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

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

ты небось когда в текстовом редакторе случайно удаляешь строчку с важным кодом — идешь харакири делать, да? сорсконтроль, undo, бэкапы — это все для слабаков. только хардкор!

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

а, ок, я подумал что вопрос про hg. да, в git всегда любое редактирование истории так работает.

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

Щас глянул - вроде дочерние комиты не пересоздаются. Просто старая ветка начинает расти в другую сторону

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

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

А это — опять централизация. Хотя у нас DVCS. Я, например, в половине случаев работаю с локальными копиями репозиториев, синхронизируя их напрямую. Тот же Bitbucket используют только для обмена полностью изолированных машин и для общего упорядочивания.

Старую историю никто не меняет. Переписывают только последние коммиты

Я же давал ссылку на тему со своей проблемой по этому вопросу. Таки, ключик «-f» там легко мог привести к потери части данных. И там половина холивора как раз шла на счёт того, нужно ли, как в Git, иметь возможность легко переписывать историю или как в Mercurial считать историю священной коровой, резать которую нужно только в исключительных случаях. А ты говоришь — никто не меняет :) Git-холиворщики в той теме, как раз, за возможность переписывания истории воевали...

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

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

Бгг.

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

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

strip удалит что угодно.

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

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

strip удалит что угодно.

можешь показать, как удалить с помощью него бренч? который есть на сервере?

Ты же и сам знаешь, что нужно залогинится по ssh и прогнать strip.

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

вышеупомянутые обезьяны даже про amend не знают.

Но я начинаю понимать... контрольный вопрос: у вас все репозитории publishing?

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

А это — опять централизация

Конечно, на выходе-то один продукт в большинстве случаев. Ты же не хочешь чтобы каждый девелопер готовил свой собственный релиз?

Хотя у нас DVCS

Не вижу противоречия. Я не верю в полную анархию в мире разработки.

Я же давал ссылку на тему со своей проблемой по этому вопросу

Можно ссылочку? А то сходу не нашёл. А то пока что для меня это выглядет как «надо запретить rm потому что у него есть ключ -f».

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

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

Полностью согласен с данной оценкой. Если не приплетать нечто вроде «а что если тебе надо будет сливать стопицот веток одновременно накладывая over9000 патчей» - к реальной работе небольших комманд такие объяснения не подходят.

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

Ты же и сам знаешь, что нужно залогинится по ssh и прогнать strip.

знаю конечно, но в git я могу и без ssh. так понятнее?

Но я начинаю понимать... контрольный вопрос: у вас все репозитории publishing?

затрудняюсь ответить, т.к. не знаю что это такое.

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

в git я могу и без ssh. так понятнее?

Это понятно уже давно, так что нет, понятнее не стало.

Но я начинаю понимать... контрольный вопрос: у вас все репозитории publishing?

затрудняюсь ответить

Значит, «да». После push на сервер ченджсеты фиксируются... я понимаю твое раздражение.

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

Можно ссылочку? А то сходу не нашёл

Да прямо в этой теме выше уже давал: Вопрос про Git. Он, правда, позволяет так легко потерять данные? — 427 сообщений срача, при чём я оттуда ушёл уже на первой трети :)

А то пока что для меня это выглядет как «надо запретить rm потому что у него есть ключ -f»

Хм. Я нигде не призываю «запретить rm^W git». Я говорю, что лично мне, с моим идеологическим подходом к истории, он подходит хуже, чем Mercurial.

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

Зависит от самой VCS. Если, например это распространённые Git, Hg, Subversion - то нормально. А если это Perforce, CVS, darcs - я бы забил с высокой вероятностью. В крайнем случае бы просто сделал локальный патч для своих нужд.

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

«Такие как все» постят фоточки вконтактике. А быть не таким как все даже среди красноглазых - это уже серьезная патология)

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

Тебе дали очень-очень дурной совет который не решал проблемы. Гит чрезмерно усложнён и у него дурацкая документация расчитанная на тех кто в теме. Для флага -f они могли бы написать что-то типа «it overwrites non-matching part of remote history and causes data loss» и тогда бы не было проблемы (если ты читал доки, конечно).

Но я бы не сказал что этот случай демонстрирует проблемы с git. Он сделал то что написано в доках и даже вывел сообщение об ошибке. И даже сообщил что надо делать.

Для чего же нужны ключи типа -f? На случай глобального ппца когда что-то вышло за рамки того что ожидали разрабы. В таких случаях очень важно иметь доступ сделать что-то очень нехорошее. Просто у руля должен быть человек который знает что делает.

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

Для чего же нужны ключи типа -f? На случай глобального ппца когда что-то вышло за рамки того что ожидали разрабы. В таких случаях очень важно иметь доступ сделать что-то очень нехорошее. Просто у руля должен быть человек который знает что делает.

Типа функция самоуничтожения для того чтобы нагадить начальству? :) Не злите Линуса! :)

I-Love-Microsoft ★★★★★
()

Я выскажу смешную аналогию, но так и линукс можно сменить на винду - ТА ПРИВЫЧНЕЕ! :)
По-моему, зараза git окончательно схавала мозг хомячкам - ну как же, САМ ЛИНУС писал это поделие! А никто не хочет спросить, ДЛЯ КАКИХ ЦЕЛЕЙ писался гит и почему вдруг все решили, что он подходит для хомячковых проектов из десятка сипипишек?

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

s/нехорошее/нестандартное/g :(. Этот как с debugfs. Обычному человеку лучше не давать.

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

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

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

На сервере можно поставить pre-receive хук, который физически не даст выполнить такой push, сколько бы --force там клиент не ставил.

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

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

anonymous
()

Только SVN, только хардкор

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

На сервере можно поставить pre-receive хук, который физически не даст выполнить такой push, сколько бы --force там клиент не ставил.

Зачем пытаться сделать VCS из гита, говна и палок? Уже есть готовая.

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

Фишка в том, что в Git придётся запрещать push -f явно и на сервере — а на каком?

фишка в том, что он по-умолчанию запрещен для bare репозиториев, а на git-серверах нет смысла держать не-bare репозиторий.

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

а у меня как-то вышло, что я сначала научился пользоваться гитом когда быдлокодил всякие драйвера и библиотеки для девайсов на винде под винду. про гитхаб тогда не слышал ничего (да и не было его еще наверное). значительно позже я узнал (прочитал) кто его автор. просто он был быстрее и удобнее чем svn, darcs и иже с ними. ну а вообще, если будет хорошая конкуренция гиту, например, со стороны hg - я только «за». ибо без конкуренции все деградирует.

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

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

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

в git это назвается «создать бранч» или «создать тэг», хотя есть и другие способы.

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

это ты мимо, история перепишется только в том бранче/бранчах, в котором ты её перепишешь, а в остальных она останется.

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

знаю конечно, но в git я могу и без ssh. так понятнее?

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

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

На сервере можно поставить pre-receive хук, который физически не даст выполнить такой push, сколько бы --force там клиент не ставил.

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

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

в git это назвается «создать бранч» или «создать тэг», хотя есть и другие способы.

Нет, по факту в гите нужно стучать по кнопкам, как мартышка, чтобы симулировать evolve.

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

Для чего же нужны ключи типа -f?

Вот, например, в Mercurial ключик -f позволяет запихнуть на сервер новую голову после конфликтов (что по умолчанию не делается без «силы»). То есть, --force указывает на принудительное исключительное действие, но которое всё равно не приведёт к потере информации. Всё же, DVCS в моём представлении — это именно система, направленная на максимально защищённое сохранение всей истории. Поэтому мне и нравится Mercurial, там практически невозможно что-то потерять, просто напутав или не поняв. Поскольку я считал такой подход для DVCS естественным по сути, я и наступил на эти грабли с Git, полагая, что он вполняет те же функции с той же философией. Оказалось — нет :)

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

фишка в том, что он по-умолчанию запрещен для bare репозиториев

Ты мою тему почитай. Я именно bare и запорол. Перенеся потом эти потери на GitHub.

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

это не так, как раз для bare-репозиториев он и не запрещён. наоборот, он запрещён для репозиториев с рабочей копией.

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

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

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

а ты внимательно читай что тебе пишут, по-умолчанию запрещен для bare-репозиториев - не значит что по-умолчанию запрещен в gthub. В github (не enterprize) вообще нельзя их запретить, насколько я помню.

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

это не так, как раз для bare-репозиториев он и не запрещён. наоборот, он запрещён для репозиториев с рабочей копией.

у тебя какой-то альтернативный git. хотя я тоже ошибся, не для bare, а для shared

By default, the configuration flag receive.denyNonFastForwards is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it.
Хотя я точно помню, что у меня в не-shared bare репозиториях он тоже включался, может это какая-нибудь особенная настройка была.

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

а ты внимательно читай что тебе пишут, по-умолчанию запрещен для bare-репозиториев

«Я именно bare и запорол». Свой, полностью дефолтовый bare.

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

да, я ошибся, смотри на одно сообщение выше.

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

ок, давай сойдемся на том, что ты не смог объяснить что evolve делает?

Ну если бы я знал, что в треде будут дети, объяснил по-другому, ок.

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

Поскольку я считал такой подход для DVCS естественным по сути, я и наступил на эти грабли с Git

этот подход естественнен для _не_DVCS.

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

ок, давай сойдемся на том, что ты не смог объяснить что evolve делает?

насколько я понял, в терминологии git, такая операция должна пометить какие-то объекты (видимо все, на которые теряются ссылки в процессе текущей операции редактировании истории), как запрещенные к удалению (gc), и заставить гит их push'ать. по дефолту, unreachable-объекты не push'атся. и делать tag на каждый такой объект - это какой-то изврат. так что да, наиболее простое решение, это перед редактированием истории создать новый бренч из того, который собрался редактировать. но может быть есть какие-то возможности, о которых я не знаю.

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