>[оверквотинг удален]
> только вот синтаксис git checkout --hard (да и семантика - причем бы
> тут - checkout?) придуман кем-то явно незнакомым с cvs и вообще
> vcs, и изобретал велосипед - ну и изобрел, с квадратными колесами
> и без цепи, надо ногами толкаться, зато так веселее.
>> Если же на более сложном уровне, то git позволяет создать внятную историю
> к сожалению, гит _форсирует_ подделку этой самой истории - потому что никаким
> другим способом даже на локалхосте работать невозможно, не говоря уже о
> совместной работе (ну если не считать таковым push -f - что
> у нас вон принято делать, но тут, традиционно, ни разработчики, ни
> тем более архитекторы проекта гитом пользоваться и не умеют) Это интересно. Если тебе не влом, расскажи мне, как в "нормальных" vcs я мог бы разрулить следующую ситуацию и получить внятную историю. Смотри, я запиливаю в проект новый функционал. В процессе я нахожу косяки в проекте не связанные с тем, что я сейчас делаю -- я могу создать issues об этих косяках, но часто проще исправить на месте. Иногда я нахожу косяки связанные с тем, что я делаю -- то есть я не могу запилить новый функционал, пока не внесу некоторые архитектурные изменения в существующий проект. Тут три типа изменений, в случае с git я могу вносить их хоть в полном беспорядке, с тем чтобы позже раскидать их по веткам с говорящими именами, а потом эти ветки красиво мергнуть в dev-ветку. Как то же самое проделать без "подделки истории"? Я ведь вношу все эти изменения не зная, что будет через полчаса. У меня есть определённый план внесения изменений, но он постоянно спотыкается о реальность и меняется.
> поэтому никакой внятной истории не получается - если проект твой личный, гит
> тебе поможет вспомнить, что ты делал, наверное, и если ты сам
> оставлял на память точки вспоминания - ветки, теги. А если не
> твой - то хрена там с два, особенно, если ты не
> знаешь заранее ответ.
История она не для того, чтобы отслеживать процесс разработки таким, каким он был. История она для того, чтобы зафиксировать и документировать изменения вносимые в проект. История должна отвечать на вопрос "зачем были внесены те или иные изменения".
>> более крупные. Впрочем, даже без этого -- беспорядочный поток коммитов вместо
>> истории тоже очень полезен для понимания происходящего.
> говорю же - cvs, 1998й год. Нет, ветки она тоже умеет. Она
> не умеет rebase.
cvs я пробовал освоить ещё до git. Ниасилил. Совершенно ненужная вещь. Может быть для командной разработки и полезно, но для локальной разработки в одно лицо -- излишество.
> зато и синтаксис, и семантика человеческие.
Да что вы так озабочены этими человеками? vcs создаётся для программистов, а не для человеков, это тот редкий случай, когда разработку интерфейса не стоит доверять UX-специалисту, а следует оставить программисту, потому что программист для программиста сделает лучше, чем UX-спец для программиста.
> А теперь, без подглядывания в шпаргалку, расскажи нам, как откатить обратно ошибочный
> git pull вместо fetch ?
В чем проблема? Как откатить назад несколько коммитов? Не заглядывая в шпаргалку, я бы предположил что надо сделать git checkout на последний правильный коммит, а затем туда перенести HEAD ветки. Последнее навскидку я не уверен как сделать. Но если без шпаргалок, то можно удалить старую ветку, и создать на этом коммите её заново. А на всякий случай, прежде чем удалять, надо... короче, чтобы было понятно, последовательность действий такая:
git branch temp
git branch -d screwed
git checkout <hash of last good commit>
git branch screwed
git branch -d temp
Я бы делал так, если бы не мог заглянуть в шпаргалку. Но я не понимаю этого искусственного ограничения: man git-branch всегда под рукой.
> (в hg такая ошибка невозможна, потому что у нее нет "третьего состояния" git add)
И как hg предлагает обходить нехватку этого третьего состояния? Оно ведь очень удобно, для создания истории в первом приближении: я собираю в коммит то, что нужно, смотрю всё ли правильно, затем делаю commit. Не совсем удобно то, что если я хочу закоммитить не все изменения в файле A, а только часть их -- приходится не на этапе git add это делать, а уже непосредственно в процессе commit'а, а в случае ошибок откатывать коммит. Но и всё же, add очень удобен. Как жить без него?
> банальнейшая ведь ситуация, если чуть в стороне от локалхоста :-(
А вот не надо спорить с самим собой. Я знаю, что это очень удобно: придумываешь такие утверждения с которыми знаешь как спорить, приписываешь эти утверждения оппоненту и споришь с ними. Лепота. Но не надо так делать. Я говорил о том, что git полезен даже при разработке на локалхосте. И могу добавить, что в отличие от cvs, которая больше путается под ногами и мешает, чем помогает.
