VS>>>> Вот в чем дело. Интересно, можно ли использовать какой-нибудь VS>>>> хук, чтобы перед коммитом проверялась свежесть рабочей копии, AK>>> зачем? В двух головах нет никакого ужаса. VS>> А если их потом станет больше двух? Как я сливать все их буду? AK> командой merge. В чем разница с up при измененном дереве?
Надо будет попробовать, может и правда не страшно.
VS>> Все операции, модифицирующие историю, мне идеологически очень не VS>> нравятся, AK> ну вот затесалось нечаянно в commit message слово #@й - и что, мне так AK> теперь и любоваться этим х#%м в каждом просмотре log? (ошибки, AK> опечатки и т д, живут вечно, потому что они у нас часть истории)
Нет, я не против поправить commit log, это же не changeset правится.
AK> И чуть реже - "ой, еще вот в этом месте поправить забыл" (а еще чаще AK> поправить не забыл, забыл основной файл добавить, а он - новый) - AK> таким правкам незачем занимать место в истории, add; commit --amend
А вот это уже зависит от восприятия истории. Можно воспринимать историю как нечто делаемое напоказ, как публикацию, и думать об её красоте. А можно просто как рабочий инструмент. Для археологов, как известно, ценны и свалки, и уборные.
VS>> может именно поэтому не глянулся git с его постоянным rebase. AK> ну, он, вообще-то, не историю меняет, он новую из пальца высасывает. AK> То что было до rebase, остается в виде мертвой ветки без имени. AK> Hо поддельная история мне как раз нравится гораздо меньше подчищенной.
