На дворе шел 2012 год

[metaclass]

Мейл-лист разработчиков некоей СУБД:
BTW, IMHO subversion is worse than CVS. I don't understand why you want to migrate at all.

Comments

[thinker8086.livejournal.com]

>> Но с одой особенностью

Это которой?

[blacklion.livejournal.com]

rebase, который не прописывается в историю. Сама идея rebase/squash/whatever хороша и иногда полезна, но это деструктивная команда, никак не отмечаемая в репозитории — ВДРУГ удалили часть коммитов бесследно.
Это никак не соотносится с хранением истории проекта. Историю НЕЛЬЗЯ переписывать.

Ну и это ещё приводит к чудесным эффектам, когда такое делают у репозитория с которым кто-то уже синхронизировался. Что приводит к тому, что все “workflow” с использованием этих команд (тысячи их в интернете) неработоспособны когда одну и ту же фичу делают несколько человек или хотя бы один человек на нескольких рабочих местах (ноуте и рабочей станции или домашнем и рабочем компьютере). Но это уже побочные эффекты изначально кривого дизайна, заложенного в этих командах.

[freiksenet.livejournal.com]

reflog же.

И вообще ребейз индивидуальная команда - сделал фичу один, ребейзнул и тд. Если над бранчем работает несколько человек то юзается бекмердж основного бранча а не ребейз.

[blacklion.livejournal.com]

reflog же.
Хм. Читаю man — не вижу при чём он тут.

И вообще ребейз индивидуальная команда
Это не важно. Важна сама штатная техническая возможность переписывать историю, никак не ограниченная вообще. Там хоть ACL'и нормальные появились? Или нет?

[blacklion.livejournal.com]

Вот если бы git сам при pull/push пользовался рефлогом (и там не было бы команды "expire") это было бы хоть на что-то похоже. А сейчас — push, ребейз, push — и репозиторий кровь кишки распидорасило а от git ни слова.

Я сам сторонник разрешения стрелять себе в ногу — но не когда речь идёт об истории, которая принципиально не должна редактироваться.

[freiksenet.livejournal.com]

Ну гит не даст пушнуть если что-то распидорасит. Только через форс, а если ругатся на форс, то можно ругатся и на то что "rm -rf /" удалит вам все файлы в руте )

ИМХО возможность поправить историю хороша при факапе. Тогда рефлог позволяет очень гранулярно откатится куда надо и иметь чистую и читабельную историю, а не полный пиздец из-за одной ошибки.

ЗЫ: Кстати в компании мы не пользуемся рибейзом вообще, только мердж. Когда есть центральный репозиторий (гитхаб) в который feature branches регулярно пушатся, рибейз не нужен.

[blacklion.livejournal.com]

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

[freiksenet.livejournal.com]

Я может туплю, но как? После второго рибейза в репозитории куда пушим будет коммит посде предыдущего рибейза, куда он денется? Если он там будет то дерево в локальном репозитории 1 ahead 1 behind и fast-forward не пройдет.

[blacklion.livejournal.com]

После второго рибейза в репозитории куда пушим будет коммит посде предыдущего рибейза, куда он денется?
Да. А так как после второго рибейза того коммита уже нет, а есть новый (пусть и стем же сожержанием ПО СМЫСЛУ, но с другой чексуммой — т.е. идентификатором), то он снова проапушится и промёржится.

У меня без всяких форсов получилось на раз-два.

[freiksenet.livejournal.com]

Блядь, и правда. Правильно мы всегда мёрдж юзаем тогда %)

[blacklion.livejournal.com]

Воот! Я на это напоролся в первый же день — я использую свой сервер как точку встречи своих двух компов (итого на одного меня три репозитория — серверный и два на рабочих станциях, общение с апстримом через сервер) и, не подумав, сразу выбрал workflow с ребейзом. Потом уже подумал, хлопнул себя по лбу, и понял, что в такой схемек ребейз делать нельзя.

[theiced.livejournal.com]

так делать низяяяяя.

Do not rebase commits that you have pushed to a public repository. (c)

а вообще торвальдс говноед ;]