>> Они становятся нужны, когда результат этого программирования выносится с твоего локалхоста.
> Не. Не знаю как mercurial, а git нужен даже для проекта который

[skip]
ты прекрасно описал use-pattern cvs (какое, милые, у вас, тысячелетье на дворе?)

этакий "умный undelete".

только вот синтаксис git checkout --hard (да и семантика - причем бы тут - checkout?) придуман кем-то явно незнакомым с cvs и вообще vcs, и изобретал велосипед - ну и изобрел, с квадратными колесами и без цепи, надо ногами толкаться, зато так веселее.

> Если же на более сложном уровне, то git позволяет создать внятную историю

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

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

> более крупные. Впрочем, даже без этого -- беспорядочный поток коммитов вместо
> истории тоже очень полезен для понимания происходящего.

говорю же - cvs, 1998й год. Нет, ветки она тоже умеет. Она не умеет rebase.

зато и синтаксис, и семантика человеческие. А если что-то пошло не так - она останавливается и ждет, пока ты сам разберешься. И 3way merge у нее, по-моему, уже тоже был - причем без использования прекрасного kdiff, который не очень здорово работает через ssh (а скоро совсем не будет, с пришествием божественного вафлянда)

А теперь, без подглядывания в шпаргалку, расскажи нам, как откатить обратно ошибочный git pull вместо fetch ? (в hg такая ошибка невозможна, потому что у нее нет "третьего состояния" git add)

банальнейшая ведь ситуация, если чуть в стороне от локалхоста :-(