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

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

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

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

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

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

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

Да, будет создан новый коммит. И все коммиты, которые от него зависят, тоже будут созданы заново.

git checkout old_branch git commit --amend

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

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

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

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

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

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

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

Бгг.

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

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

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

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

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

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

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

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

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

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

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

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

Хотя у нас DVCS

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

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

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

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

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

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

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

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

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

странно. мне казалось, что сейчас наоборот модно быть «не таким как все»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

git push -f

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ты вообще мимо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

это не так, как раз для 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.

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

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

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

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

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

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

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

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

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

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