Не могу осилить git

>да это неприятно когда по недосмотру в истории видны сломанные под другой платформой билды и прочие недисциплинированные вещи. И все смотрят и хихикают. Но это лучше чем орлы удаляющие историю файла с невинным видом и словами «да там всего 2 ревизии» (c) сам видел.

Поддерживаю.

В совсем уж клинических случаях reset на git-сервере никто не отменял.

>удаляющие историю файла с невинным видом и словами «да там всего 2 ревизии»

расстрэлять

http://progit.org/book/ru в помощь.

Сам по ней осваивался.

Спасибо.

Да не за что.

Найти бы похожую по Bazaar еще...

> Но это лучше чем орлы удаляющие историю файла с невинным видом и словами «да там всего 2 ревизии» (c) сам видел.

А кто дал орлам такой доступ к центральному репозиторию?

Если для изучения такого инструмента как система контроля версий нужна такая толстая книга, то с значит с этим инструментом что-то не то. mercurial и svn я изучал по hg/svn help.

Не люблю help. Мне нравятся более структурированные способы подачи информации.

Кстати, уже нашел.

http://bzr-day.blogspot.com/p/bzr-day.html

Если для изучения такого простого инструмента как git кому-то эта толстая книга понадобилась, значит с этим кем-то явно что-то не то.

> Если для изучения такого простого инструмента как git кому-то эта толстая книга понадобилась

Прикинь, таких много :) Потому что и книг много. Может, это с инструментом что-то не так?

Да все с ним в порядке, сколько можно ныть?

> Да все с ним в порядке, сколько можно ныть?

Веско, убедительно.

Примерно на том же уровне что и «гит сделан для инопланетян».

> Примерно на том же уровне что и «гит сделан для инопланетян».

«Для инопланетян» - это метафора, означающая «сознательно сделан так, что нарушает все привычные соглашения о командах VCS, причем без всяких причин».

И ты сам сказал:

dmsh> кому-то эта толстая книга понадобилась, значит с этим кем-то явно что-то не то

Так вот, толстые книги по Git понадобились и существют. Можно сказать, что это пользователи тупые, а можно сказать, что Git сделан бессмысленно сложным. Я понимаю, назвать других тупыми проще и приятнее.

Что это за «соглашения» такие? И почему именно гит их нарушает?

Подумаешь, fetch и pull местами поменяли, трагедия какая.

Вот, кстати, для неосиляторов и любителей поныть про «сложность». Найди 10 отличий: http://mercurial.selenic.com/wiki/GitConcepts

Я табличку внизу имел в виду http://mercurial.selenic.com/wiki/GitConcepts#Command_equivalence_table

> Что это за «соглашения» такие?

Поработай с svn и hg - поймешь. Bzr сюда же.

И почему именно гит их нарушает?

Потому что так захотел Линус. Официальную отмазку ты можешь найти в архивах git@ за весну-лето 2005 г.

Веско, конструктивно.

> Веско, конструктивно.

А ты ожидал покомандного сравнения? Я давал уже ссылку на Rosetta stone.

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

Я написал конкретно, чего мне надо:

Что это за «соглашения» такие? И почему именно гит их нарушает?

Ну даже если и есть какие-то соглашения, в чем я сильно сомневаюсь, ну даже если гит их и нарушает, что с того? Даже если злостно нарушает, каким образом это делает его автоматически «неоправданно сложным»?

Феерично. Самое смешное, что в git иногда предлагают одно и то же делать разными командами. Вот например злосчатный revert:

hg revert -a 	git reset --hard 
hg revert some_file 	git checkout some_file

> Если для изучения такого инструмента как система контроля версий нужна такая толстая книга, то с значит с этим инструментом что-то не то. mercurial и svn я изучал по hg/svn help.

C ClearCase не работали?

> Даже если злостно нарушает, каким образом это делает его автоматически «неоправданно сложным»?

*shrug* Тем, что приходиться учить еще и специфично-гитовские трюки. При том, что ничего нового они не несут.

Впрочем, если ты ничего, кроме Git, не знаешь, это для тебя не аргумент.

>что с того?

А очень простое рассуждение. Какой профит мне может дать Git, по сравнению с Mercurial чтобы оправдать свой наркоманский набор команд? Совершенно никакого. Вывод: Git используют только модницы.

И что тут фееричного? Что ты не догадался, как убрать все изменения с помощью cheсkout?

git checkout -f HEAD

Проблема решена?

С любой программой приходится учить специфичные для нее трюки, это вообще не аргумент ни для кого.

Почему гит должен что-то оправдывать? Поменяй гит и меркуриал местами и перечитай свое «рассуждение» еще раз.

Если поменять местами, то только из этого рассуждения видно как минимум одно очевидное преимущество: у hg набор команд не наркоманский. Это даже ты понимать должен, ну же.

> С любой программой приходится учить специфичные для нее трюки,

Да, да. Конечно. Приходится. Но прикинь, для меня освоить Mercurial после SVN было проще, чем Git после Mercurial. А знаешь, почему? Потому что Git был специально сделан непохожим ни на что. _Специально_. И при этом еще и неудобным, да.

это вообще не аргумент ни для кого.

Это не аргумент лично для тебя, не более.

Если настоящих аргументов (а не «наркоманы/инопланетяне/модники»), с вашей стороны не предвидится, я предлагаю на этом закончить.

Раз уж у нас тут вечер откровений, то и я, пожалуй, признаюсь. Я в свое время совсем не осилил свн, а после этого запросто осилил гит. Вывод?

А настоящие аргументы уже приведены. Достаточно сравнить таблички по ссылкам

https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone

и

http://mercurial.selenic.com/wiki/GitConcepts#Command_equivalence_table

Это не аргументы, а таблички. Сформулируй уж явно, от чего тебя так коробит, глядя на таблички. Я вот не вижу принципиальной разницы, например.

> Раз уж у нас тут вечер откровений,

Упаси ТНБ, просто честный разговор.

Я в свое время совсем не осилил свн, а после этого запросто осилил гит. Вывод?

Предагаешь поставить тебе диагноз по аватарке? Ну, попробуем. За «после» ты кое-чему научился? Или ты хотел осилить Git, чтобы быть как Линус? Или ты используешь Git как недо-SVN?

Я вот не вижу принципиальной разницы,

Еще раз: у потомков Monotone не может быть принципиальной разницы.

• Одна команда используется чтобы делать много слабо связанных вещей. Пример с revert выше по треду
• Как старый и говорил, полный игнор соглашений.
• Непонятные команды. Во время освоения hg и bzr я очень часто просто угадывал нужную команду. С git такое совершенно не прокатывает, нужно каждый раз лезть в man
• hg сделан так, что при правильном workflow (уделять внимание .hgignore, следить, чтобы у каждой ветки была только одна голова и т. п.) почти все команды используются без опций. В git всё не так.

Предагаешь поставить тебе диагноз по аватарке?

Нет, все мои диагнозы мне вроде бы известны.

Еще раз: у потомков Monotone не может быть принципиальной разницы.

Ну и зачем тогда все это бесконечное нытье про «сложность»? В чем сложность, откуда ей взяться?

> В чем сложность, откуда ей взяться?

Тебе это уже много раз объясняли, но ты принял объяснения за нытье. Впрочем, это твоя личная проблема.

</thread>

Одна команда используется чтобы делать много слабо связанных вещей. Пример с revert выше по треду

Хватит бредить. Какая конкретно команда и какие слабо связанные вещи она делает?

Как старый и говорил, полный игнор соглашений.

Никаких соглашений не существует, а если даже и существовали бы, никто не обязан им следовать.

Непонятные команды. Во время освоения hg и bzr я очень часто просто угадывал нужную команду. С git такое совершенно не прокатывает, нужно каждый раз лезть в man

Гадание на кофейной гуще в общем случае нигде не прокатывает. Это не аргумент.

hg сделан так, что при правильном workflow (уделять внимание .hgignore, следить, чтобы у каждой ветки была только одна голова и т. п.) почти все команды используются без опций. В git всё не так.

Пустопорожний треп. Где конкретные примеры?

Какое объяснение? Что в гите специально проигнорировали какие-то там надуманные соглашения? Ну и ладно, это законный выбор автора, в конце концов. Каким образом игнорирование соглашений делает программу сложной? Тебе она показалась сложной? Допустим, но это уже твои личные проблемы.

Надеюсь, всё у тебя будет хорошо.

>Хватит бредить. Какая конкретно команда и какие слабо связанные вещи она делает?

В таблице. Слабо связанные. Хватит шлаговать, а?

Никаких соглашений не существует, а если даже и существовали бы, никто не обязан им следовать.

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

Гадание на кофейной гуще в общем случае нигде не прокатывает. Это не аргумент.

Но существенно сокращает время поиска в справке.

Пустопорожний треп. Где конкретные примеры?

push, pull, up, add, ci. Мало?

На самом деле, хорошо, что есть гит и гитхаб и ещё куча модных штук. По ним сразу видно человека. SVN-ом пользуются зануды, меркуриалом - нормальные прагматики, базаром - тоже обычно приличные люди, а гитом - либо инопланетяне, а либо воннаби с молескинами. И сразу понятно, с кем не надо связываться.

В таблице. Слабо связанные. Хватит шлаговать, а?

Конкретный пример. Команды. Его, по-прежнему, нет. Хватит высасывать из пальца, а?

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

Аналогии не рулят. Это ваш единственный полуаргумент, который вы сами же сводите к вопросу привычки.

push, pull, up, add, ci. Мало?

Это набор команд. И? К ним иногда нужно добавлять ключи, как в гит, так и в хг. Сказать-то что хотел?

И сразу понятно, с кем не надо связываться.

С любителями ставить диагнозы по scm.

Конкретный пример. Команды.

git checkout [<branch>], git checkout -b|-B <new_branch> [<start point>]

  This form switches branches by updating the index, working tree, and HEAD to reflect the specified branch.

...

git checkout [--patch] [<tree-ish>] [--] <pathspec>...
  When <paths> or --patch are given, git checkout does not switch branches. It updates the named paths in the working tree from the index file or from a named <tree-ish> (most often a commit).

Нормальненько так, да?

Это ваш единственный полуаргумент, который вы сами же сводите к вопросу привычки.

Суть не в том, что git непривычен. Суть в том, что git непривычен безо всякой на то причины.

К ним иногда нужно добавлять ключи, как в гит, так и в хг. Сказать-то что хотел?

Что в hg иногдее.

В общем, я спать.

> Нет такой болезни. «Git головного мозга» есть, а «mercurial головного мозга» - нет.

Воистину. Причем больных git'ом головного мозга толпы, взять тот же programming на c.j.r. — целиком из фанбоев git'а состоит. Хотят Линусу подражать, вестимо.

Как с hg сделать git commit --amend ?