Pull to refresh

Comments 134

1) А я обычно работаю с hg через консоль, даже если редактирую исходники через IDE с поддержкой hg.

2) Про последние замечания: если в IDE будут свои термины и свои методы работы с репами, то людям, уже знакомым с нужной DVCS, будет только больше головняка. Помню как я подвисал в netbeans, пытаясь понять, что значат те пункты меню, которые не совпадают с терминами hg.
Тоже через консоль работаю, но иногда использую diff merge в качестве внешнего diff.
Я тоже очень часто работаю с git в консоли, хотя когда подключил к Emacs-у magit — начал потихоньку забивать. Основная причина — из magit значительно удобнее стейжить отдельные файлы.

Автору:
К git в больших проектах следует относится скорее не как к системе контроля версий, а как к конструктору любой системы контроля версий. В зависимости от предпочтений и стиля разработки, к нему можно один раз написать набор скриптов, покрывающих весь development routine, и больше не вбивать одни и те же комманды по несколько раз.
Svn+eclipse — для меня слишком удобно, чтобы пытаться изучать и привыкать к чему-то еще. Заморачиваться с выбором инструмента контроля версий — выше моих сил.
сочувствую
ладно вы не видели Idea, но вы даже TortoiseSvn не видели
svn в эклипсе — в некоторых случаях даже командная строка удобнее
А большая команда разработки, в которой вы состоите? Если состоите, конечно.
5 человек, код которых может пересекаться при коммите, 40 человек всего.
Статья похожа на перевод :) А так да, почти все по дело, хотя по-моему у Меркуриала все не так плохо. По-крайней мере все каманды вполне логичны.
Опять же Backout и Strip ревизии у меня никогда не вызывали проблем(commit amend == Backout так ведь?)
Но, таки да, вот такие вещи в истории убивают:
habrastorage.org/storage/3449db33/2f7fc601/3d3dca21/03eedec2.png
Но можно упростить, включив Compact Graph
habrastorage.org/storage/ff20f07c/44683672/498bfc41/84de1220.png
Блин, картинки не вставляются.
Зачетные картинки! А что за программа?
их „продвинутый“ функционал — это тот же самый набор консольных утилит, для которых просто есть кнопочки в интерфейсе
естественно. ведь libgit нет и не предвидится (за исключением dulwich).
А разве в самом git-е внутри не набор гибких низкоуровневых утилит, с помощью которых можно делать с репозиторием что угодно?
Можно-можно. Это если
а) разобраться, что делает каждая из них
б) разобраться, какие команды и в каком порядке вызывать
в) разобраться, почему именно в таком порядке
г) разобраться, что вызывать, если что-то пойдёт не так
д) во всех предыдущих пунктах — курить ключи форматирования вывода на предмет сделать его пригодным для парсинга и парсить-парсить-парсить stdout+stderr. Другого пути нет в принципе (не считая помянутого dulwich).
Inb4: нет, это никакой не unix-way, дорогие фанбойчики. Это самый что ни на есть кровавый enterprise эпохи CP/M и MS-DOS.
В случае с mercurial можно хотя бы на питоне сказать import hg и жонглировать репозиториями в хвост и в гриву. Даже всеми гонимый svn есть фронтенд к libsvn, которую, к слову, и используют всяческие фронтенды (к слову, libчтототам + пачка фронтендов — это и есть unix-way).
UFO landed and left these words here
dulwich не требует установленного git. git-python — требует
я вот бы с удовольствием послушал рассказ парней из JetBrains о том, как они приручали эти «гибкие низкоуровневые утилиты», когда писали поддержку Git в IDEA сотоварищи
Странно, правда, только вот что —
а) почему её не используют Торвальдс сотоварищи?
б) почему её нет в репозиториях?
Почитал, как у них переписывается история, чтобы сделать commit amend — это ритуал с тремя получасовыми заклинаниями и одним „расширением“
попривыкали, панимашь, историю править со своим гитом.
установка расширения заключается в том, что ты в конфиге прописываешь его название — типа до этого Меркуриал ничего о нем не знал, а теперь вот узнал
установка — это sudo pypi-install mercurial_keyring. а «прописать в конфиге» — это включение. так, знаете ли, существенно гибче, ЕВПОЧЯ.
Мне как пользователю хочется пользоваться. Пусть при первом вызове расширения он его сам скачает, установит и включит.
с данными запросами — в багтрекер, будьте любезны.
Расширение уже входит в комплект и ничего скачивать и устанавливать не надо. Просто оно отключено по умолчанию.
так на самом деле и не понял, почему git — «нелогичный набор утилит командной строки».
это похоже на то, если бы я жаловался на vi — «как это можно столько команд запомнить? как-то все непросто… и GUI нет? кто ж будет в консоли код редактировать?»
по-моему, git — очень удобный инструмент, всегда работаю с ним только из консоли, ничего лишнего, как и все профессиональные инструменты — мощь и простота в одном.
Потому что перемещения между четырьмя хранилищами (к примеру):
а) каждое называется своим словом, причем в него не входит имя хранилища,
б) некоторые разные перемещения выполняются одной командой + аргументы, в которых опять-таки не учавствует имя хранилища.

То есть, чтобы этим рулить, надо запомнить эн несвязанных слов и их соответствие реальности. Это я называю нелогичностью. Интерфейс поверх — чтобы не запоминать, чтобы не лазить в ман.

В vi все нормально — его текстовость ему не мешает. А в такой сложной визуальной штуке, как репозиторий, было бы более к месту непосредственное оперирование деревом, драг-унд-дроп какой-нибудь.
честно, ничего не понял…
примеры для а) и б) можно озвучить?
репозиторий необязательно должен быть визуальным, есть best practices в программировании, есть подобное и в организации работы с репозитариями. если следовать хотя бы некоторым из них — совсем необязательно «видеть» все дерево и оперировать на нодах.
Вот примерно:


Я лично системы в этих командах не вижу. Просто эн слов. И тут еще не затронуто перемещение по дереву.
соглашусь лишь с тем, что из этой диаграммы мало что можно понять, лишь глядя на нее. хотя если разобраться, то все верно. просто неудачная диаграмма, мне кажется — это лишь пример работы с git.
Нет-нет, это как раз удачная! Неудачная — это что-то типа

Полностью согласен с вами, также работаю с git — очень удобно, особенно когда нужно переносить проекты с компа на комп через флешку. Также работаю и c hg, но после git чуствую себя не в своей тарелке.
вот такой оффтопичный вопрос
почему добавление в staging называется git add filename, а удаление оттуда git rm --cached filename.

Или есть другой вариант?
Как заанстеджить все файлы? А все файлы соответствующие маске?
for i in `git status --porcelain | grep '^D.*\.foo$' | sed 's/^D \+//'`; do
    git reset HEAD "$i"
    git checkout "$i"
done

для файлов по маске *.foo
найдено в stackoverflow если что, мне пока что не приходилось с подобным сталкиваться. если не секрет — в svn это делается проще?
да я вот тоже находил это на stackoverflow, но сомнительное решение

особенно если учесть что git add dir/subdir может загрести пару временных файлов случайно и их хочется так же легко и непринужденно убрать из staging.

в svn — если мне не изменяет память svn checkout?
хотя нет, unstage — противоположность add? тогда reset только индексы изменит. да, не приходилось добавлять и удалять много файлов за раз.
не поймите неправильно, мне нравится гит, но хочется его использовать как-то эффективнее что ли, уловить стройность команд и аргументов, как к примеру приходит понимание Perl-а
я с svn загнул потому что в svn вообще нет staging :)
да, можно использовать git add -i
это практически GUI, почитал книжку и наверное теперь только им и буду пользоваться
было бы интересно увидеть предложения по возможному интерфейсу для git или hg.
Сам далеко не на всю использую гит — больше для синхронизации локал репозитория с продакшеном — ни о каких слияниях не ведаю.
Предложения-то есть, но их много. Как будут оформлятся, буду держать хабр в курсе. Это только начало пути. В конце, надеюсь, всем станет хорошо.
Пробовал использовать gui-ные клиенты, в частности для git / hg. Всё такое непонятное, по-моему в консоли в данном случае проще и быстрее работать. Скажем, hg sum --remote опишет весь статус дерева в простой и лаконичной форме, чтобы получить столько же информации из окна программы, в него нужно две минуты смотреть.
Ха-ха, 5 баллов! Первая часть с описанием систем — именно так, как все и есть. Пока сижу на SVN, как-то привык, во всяком случае с логами не так запутанно как в git'е. Да и tortoisesvn помогает. Наверное, надо тоже выписать git команды на листочек. :)
Qgit — такой же кошмар, как и всё остальное, описанное тут. Проще в GitHub'е посмотреть, что где.
Да что ж все так с этим Git носятся… SVN нормальная система, пользуемся ей при разработке (клиент интегрирован в Zend Studio) — вопросов никаких — всё нормально… зачем париться и переводить всех на Git, если есть SVN?
каждому свое, как говорится. почему же люди переходят со старых систем на новые? сам Торвальдс отвечает на многие вопросы о гит. хотя бы вот это видео посмотрите (на русском) www.youtube.com/watch?v=BtAlN4MaBr8
а) локальные коммиты + редактирование коммитов перед пушем.
б) локальные ветки.
в) нет проблем с мержем (в svn при отделении ветки обратно ее можно смержить только один раз, что ли. А практика показала, что там еще какие-то странности вылезают).
г) ну и скорость.
д) работа в оффлайн еще, иногда.
Порог вхождения в РСУВ (DVCS) высок. Многие не пользуются ими не потому что думают, что это им не нужно, а потому что это на самом деле сложно. В том числе программисты, которые в большинстве своем тоже люди.

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

ну просто в виндусе консоль настолько убогая, что ею стараешься не пользоваться никогда
да, кстати, в стандартной консоли cmd.exe работать тяжко, видел как это делают, получается всё очень медленно… я работаю через Far + иногда через кнопки в editplus, очень редко через netbeans
UFO landed and left these words here
Окей, давайте поставим вопрос так: почему git/hg сделаны так, что ими могут пользоваться только программисты?
UFO landed and left these words here
Хорошо, почему тулзы, которые нужны не только программистам, рассчитаны только на программистов?
UFO landed and left these words here
Нет, я из тех, кому „Пару консольных команд… выучить сложно“. Ну и дизайнеры — они не люди? Технические писатели?
UFO landed and left these words here
Глупо-не глупо, но так работает прогресс.
UFO landed and left these words here
Необязательно технические писатели, любые: чем пользоваться им? Особенно, если творчество коллективное. Движками вики, другого ничего не остаётся подходящего обычным пользователям — не программистам?

Но вики не годятся для предпечатной подготовки. Чем пользоваться редактору/редакции при подготовке книги к печати, а именно для отслеживания процессов вёрстки и корректуры-вычитки?

Скрибус, как я понимаю, имеет бинарный формат и потому не прикручивается к системам контроля версий, TeX/LaTeX и сам по себе по юзабилити убойный, а если ещё надо объединить с системой контроля версий, то вообще ппц, неспецы не осилят.
UFO landed and left these words here
> Для коллективного использования есть издательские системы

Какие? Adobe и QuarkXPress? Группа, к примеру, учёных должна ставить себе этих монстров, чтобы совместно написать статью или учебник? Я уж не говорю — покупать за деньги. Я, кстати, не уверен, что с управлением версиями там и коллективной работой там всё есть, что нужно.

Средства, как бы имеющиеся в MS Office или Open Office, для коллективной работы не годятся, ибо крайне убоги. А для предпечатной подготовки эти программы тем более не предназначены.

> Для остальных вот

И что — вот? Там нет ничего подходящего. Видно, что Вы сами не копали. К сведению: поиском по интернету я пользоваться умею.

> Бинарный формат сам по себе не помеха использования VCS просто текст-ориентированные системы с ними теряют смысл. Но историю хранить можно.

Вот именно, что теряется смысл.
UFO landed and left these words here
UFO landed and left these words here
Вы еще спросите, почему все IDE, а также emacs и vim сделаны так, что ими могут пользоваться только программисты.
IDE весьма успешно пользуются и не-программисты в вашем понимании, например я.
Исренне не понимаю, что сложного. Сам пользовался SVN и Hg (под Windows, из клмандной строки и с Tortoise* клиентами), за несколько дней осваиваешь, коммит — апдейт — пуш/пулл — просмотр истории, все элементарно и понятно. Все изменения в файле подсвечиваются разными цветами, очень просто.

Или вы ветки/теги создаете, форки и мержи делаете? Ну так либо освойте магию командной строки и силу воображения, либо мучайтесь дальше, Буратино вы наш. Это кунфу отнюдь не для людей, неспособных на что-то более сложное, чем «плагин к эклипсу» (хотя я сам не очень понимаю, зачем все эти сложности вообще нужны).
Вы, видимо, не поняли. С Гитом у меня все прекрасно, я его освоил, именно из командной строки. Но мне не нравится это положение вещей. Или вы из тех, кто считает, что серьезные вещи обязательно должны делаться сложно?
UFO landed and left these words here
Чёрт, среди множества людей, большинство из которых почему-то стремятся к усложнению, очень редко встречаю человека, который стремится к ясности и простоте.
Виват!
минусующих прошу объяснить чем checkout, merge, pull (--rebase), branch сложны и почему ими нельзя пользоваться?
Я склонен согласиться скорее с собственными наблюдениями и аргументацией в статье выше, чем с вашим, не слишком аргументированным, заявлением.
Фразы вроде «гит — это просто» или «а что не так в линуксе с отрисовкой шрифтов?» вызывают во мне такой взрыв негодования и справедливой аргументации, что я, пожалуй, лучше промолчу.
простите, ниже напишу более аргументированно.
в вашем, тоже далеко не самом аргументированном, ответе вы говорите об аргументации в статье. я увидел только два «аргумента» — GUI клиенты не умеют делать ничего, кроме отрисовки структуры и коммита, и то, что они делать не умеют.
не соглашусь с обоими — 1) есть proprietary клиенты для гит, которые могут больше, чем простой коммит (этой системой моя компания пользуется внутри, но я все-таки предпочитаю консоль) 2) «правильной» отрисовки не существует, потому как разным людям нравятся разные стили.
другого в статье не увидал, увольте, давно в России не был, быть может что-то пропустил. я уже писал выше, что так и не понял примеры про перемещения и хранилища автора статьи, он пока что мне не ответил.
уфф, передохнуть надо, давно я по-русски столько не писал, ниже отвечу, почему мне кажется, что гит — ясно и просто.
все нижесказанное — мое личное мнение
1) гит ясен прежде всего своей структурой — разветвленная дерево-подобная цепочка коммитов. вся история создания продукта — как на ладони, никто не боится создавать дополнительные ветки, разработчики не наступают друг другу на ноги — у каждого своя ветвь. в svn все время боялся создавать новые ветки, потому что merge двух веток — жестокое упражнение, которое нужно было планировать заранее, чтобы никто во время мерджа случайно чего-нибудь там не обновил.
2) использование хэшей и тагов — любому программисту придутся по душе имена нодов, все уникальны, можно «перенестись в прошлое» без каких либо проблем
3) использование stash — невероятно удобно, если под рукой вертится кто-то, кто постоянно спрашивает, что да как происходит в master и какой-нибудь другой ветке (PM например) — не нужно суетиться и сохранять все то, над чем работаешь в данный момент (может оно и не компилируется вообще) — сохранить в stash и вернуться на исходную — одна комманда.
4) bisect просто незаменим, если работаешь в большой комманде и в день набегает по нескольку сотен коммитов — попробуй найди потом кто и когда закоммитил код, который что-то там сломал
5) git хранит полную историю — файлы, которые были когда-то давно добавлены и удалены, их можно вернуть когда угодно.
6) независимость от центрального репозитория — моя копия всегда хранит ВСЮ историю, из нее можно полностью восстановить репозиторий.
7) pull --rebase — очень удобен для слияния веток, если автоматически merge не происходит, rebase остановится, даст возможность вручную исправить код, rebase --continue продолжит merge, --abort вернет все на исходную
8) dry-run (для патчей --check) — предпросмотр, очень полезная штука, покажет где и почему произойдут ошибки merge
9) отсутствие бестолковых .svn папок — не люблю мусорить там, где работаю
10) cherry-pick — одна из моих любимых комманд, выборочно применяет коммит с определенным хэшем — легко проверить, что работает, а что нет.

я не агитирую никого за использование git, мне лишь непонятно то, почему люди им не пользуются. да, возможно, learning curve у него покруче остальных, но совсем необязательно пользоваться всеми коммандами гита, начинать можно с самых базовых, постепенно осваивая новые. это инструмент, прежде всего, как и у любого инструмента у него есть преимущества и недостатки, лично для себя его преимущества помогли мне стать намного эффективней, только и всего.
5) git хранит полную историю — файлы, которые были когда-то давно добавлены и удалены, их можно вернуть когда угодно.


Справедливости ради надо сказать, что это не совсем правда. В git вполне можно, при неосторожном обращении, потерять что-то важное.
Создаете ветку -> добавляете файлы -> удаляете ветку.
Все — ваши файлы буду жить до первого git gc.
В меркуриале, как я понимаю, ничего никогда не исчезает в принципе.
Ну… там можно сделать strip :)
whybetterthanhg —
* Cheap Local Branching — mercurial.selenic.com/wiki/LocalbranchExtension
* Staging Area — не факт, что её наличие лучше. Ведь есть RecordExtension, crecord и выбор hunkов в tortoisehg
* Github — hg-git же. Причём с точки зрения юзера не меняется ничего, кроме урла репозитория.
…как, это всё?
я вроде упомянул, что это не мое мнение, на сайте есть disclaimer — можете написать Scott Chacon письмо, если вы не согласны, код сайта в открытом доступе в гитхабе. я про hg не знаю ровным счетом ничего, я даже спорить не собирался про то, чем лучше git, потому что уверен, что сколько людей — столько и мнений. а сайт написан человеком, который дал сравнение git с другими системами.
это вы про какой-то ещё не написанный git говорите. потому что mercurial определённо проще
«mercurial определённо проще» — это аргумент? я с mercurial не работал, уверен, что не все из здесь присутствующих с ним работали, так объясните, чем он проще.
Это впечатления. Я в своё время, попользовав git в течение полугода, освоил mercurial за… ну пусть будет за день подсматривания в первый попавшийся cheatsheet.
каждому — свое, просто я думал, что слово «определенно» несет за собой нечто большее, чем собственные впечатления. я вот своими поделился — про то, что гит «ясно и просто» — людям это почему-то не понравилось.
Чуствую скоро будут священные между инструментами управления, как с языками программирования )
Уже есть, я уже пару раз холиварил на тему svn vs. git. Вот только никто так и не привел мне вменяемых аргументов чем гит лучше. Считаю, что и то и другое хорошая штука которой можно пользоваться, по крайней мере у меня за три года использования svn проблем не возникало.
У вас, наверное, просто относительно поступательная разработка.

Вряд ли у вас были задачи вроде: Support<A,B,C,trunk> = «работать над A на основе trunk, потом срочно разработать фикс B на основе trunk, подать B на тестирование, вернуться к A, дорабатывать, сделать исправления по результатам тестирования к B, подать B на тестирование, делать фикс C на основе trunk, зарелизить B, отдать на тестирование A, отдать на тестирвоание C, выполнять Support<D,E,F,B>, параллельно релизя A и C и мержа результаты вышеописанного процесса в trunk»

Сам пользуюсь git, при том, что основной репозитарий — svn и мержи приходится делать rebase`ами. Даже при этом удобство неописуемое — в описанном выше процессе не приходится постоянно заниматься конфликтами или молиться на svn`овский мерж, что бы он «не потерял» репозиторий.
В gitk я смотрю разноцветное дерево только для ощущения масштабности работы, никакого практического применения я ему не нашёл. В этом случае как раз большой плюс, что история запутанная и дерево получается развесистым, так оно сильнее внушает.
Согласен с тем, что изучить Git непросто. Но все становится гораздо очевиднее, если потратить немного времени на изучение внутреннего устройства репозитория. Могу посоветовать книгу Git Internals от Peepcode. Признаться, долго сокрушался и приводил в порядок свой первый репозиторий после ее прочтения ;)
P.S. Кстати, слышал мнение о том что некоторые другие DVCS, например Mercurial и Bazaar проще для понимания, но сам ничем кроме Git никогда пользовался (даже SVN), поэтому сравнивать не могу.
в случае с mercurial вам не нужно читать hg internals, чтобы понять, как с ней работать и почему именно так. честно-честно.
Пытялся смотреть в сторону других VCS, но в результате до сих пор на SVN. Он, конечно, медленный и печальный, зато простой и удобный. А медленность и печальность отлично лечатся SSD.
Это git и mercurial для вас сложные? Ничего IBM Rational ClearCase доберётся и к вам, вот тогда и поговорим о сложности.
А вообще Tortoise HG/Git достаточно упрощают интерфейс. Я за час обучил инженеров электронщиков, которые до этого ничем кроме проэкт21.01.2003.12.34.rar не пользовались и ничего освоили успешно и довольны и почему то не жалуются на сложность.
IO_PURGATORY — это сильно
Странно, что среди нескольких gui-клиентов для git под mac не был упомянут SmartGit. Ведь весьма популярный и удобный на мой взгляд клиент.
Не всех покемонов я собрал, да.
Я так и не понял, о чём статья? О том, что все GUI фигово деревья рисуют? Или о том, что командная строка отстой? Напишите тогда ваше видение того, как надо работать с DVCS, у Mercurial есть API. Вы ведь не кричите, что вам стиральной машинкой пользоваться непонятно, а читаете инструкцию. Почему тут не хотите? Вы же программист, а не дитё малое.
P.S. TortoiseHG.
Короче смысл статьи в том, что DVCS — это немного сложнее, чем VCS. Плюс у DVCS еще достаточно плохо проработаны гуевые тулзы.

Что касается TortoiseHG, мне не нравится в нем одно: у него все окошки сильно отличаются от TortoiseSVN, которым я пользовался несколько лет и к которому привык. Когда приходится иметь дело и с hg, и с svn (в некоторых проектах до сих пор сидят на нем), то бесит переключаться между одним GUI и другим.
Я думаю, что человек, придумавший стиральную машинку, тоже сначала долго возмущался необходимостью стирать на доске.
Попробуйте Darcs. У него есть свои минусы, да, но зато очень дружественный консольный интерфейс.

Под дружественным понимается «спрашивает вопросы». Например, набираете darcs whatsnew и darcs сам запускает less, показывая вам изменения в репозитарии относительно некоторого baseline. darcs record показывает изменения в репозитарии, спрашивает, «нужно ли вот это изменение записать?» — а вы отвечаете «да», «нет», «запиши сразу все» и т.д. Даже простой запуск darcs без аргументов выдает справку, которую можно просматривать (а не дамп в stdout, как обычно). В общем, более общительный инструмент. :)
UFO landed and left these words here
Ну с этим-то никто не спорит (кроме того, что git, в отличие от меркуриала, вроде именно ревизии хранит, а не ченжсеты)
кроме того, что git, в отличие от меркуриала, вроде именно ревизии хранит, а не ченжсеты

Феерический бред.
Вы меня извините, если я не совсем в тему, но заголовок топика следовало бы расширить до «Взгляд пользователя Eclipse». Пока не дочитал до момента с пояснением того — как вы используете VCS — сильно недоумевал.
Тогда уж «взгляд пользователя eclipse, mac os x, двух мониторов и деревянного стула». Что-то я программирую в eclipse, но версиями всегда рулю сторонними утилитами.
UFO landed and left these words here
Почему на Винде нужны, а в Линуксе не нужны?
UFO landed and left these words here
В маке тоже есть консоль, которой можно пользоваться, однако мне НУЖЕН гуишный клиент. Более того, сядь я работать за линукс, он мне точно так же был бы нужен. Его, может быть, не было бы, но он был бы мне нужен.
UFO landed and left these words here
Видимо, вы неправильно понимаете значение слова „нужны“. Вы его, видимо, путаете с „можно обойтись без“.
UFO landed and left these words here
Еще раз, ну последний уже наверное. Если удобного инструмента нет, это не значит, что он никому не нужен.
UFO landed and left these words here
> Инструмент нужно использовать по назначению, а не обсжудать «неудобство рисования векторами в фотошопе и проблемы работы с растром в иллюстраторе».

Есть люди, которые используют, что им дают, а есть те, кто думает, как сделать лучше. Очевидно, что при встрече они не понимают друг друга. Извините.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Я против гуёв для программистов, по следующим причинам:
0. Гуй может увеличить эффективность только в некоторых редких операция, в большей части случаев он не приносит пользы, а часто бывает и вреден, операции с мышью они обычно тормозные.
1. На сервера ходишь по ssh — если вдруг нужно срочно что-то сделать, нужно не мануалы по командам читать и не любимы гуи ставить, а вводит давно выученные команды.
3. Всякие ide и графические клиенты скрывают от программиста как это устроено, подсевшие с юности на ide часто ничего не знают про то что компилятор, отладчик и текстовый редактор это разные компоненты, и про систему сборки могут не знать. Для кодеров может это и хорошо, а для разработчиков плохо.

Это касательно программистов, для остальных скажут так, если хочется фичей, то придётся немного подучиться, а кому фичей не надо, для тех есть соответствующие гуи. Я был бы только за, если бы был крутой гуй для все VCS, но потребности у меня в нём нет, и судя по комментам я не один.
Надеюсь вы найдёте/напишите/поспособствуете написанию удобного гуя, и весьма вероятно, если он реально будет прост, он поможет многим непрограммистам влиться в мир пользователей VCS.
Всегда придерживался такой методики обучения новому языку, технологии и т. п. — сначала разбираюсь с консольными команды, ключами, структурами, форматами и т. п., а потом, разобравшись хотя бы с основами, ищу гуевины под них. Фейл был только один (вернее много, но однотипные — продукты для разработки от MS, от Borland разобрался всё же). Мне так удобнее и эффективнее получается работать (засекал по таймеру не раз, прочитав очередной пост или тред на хабре об эффективности работы в консоли с vim или emacs в качестве ide). В гуевинах, кстати, интенсивно использую хоткеи. Главный плюс гуевин для меня возможность визуально выбирать элементы в списках, деревьях и т. п., а не долбать tab и нажимать y в ответ на «Display all 3770 possibilities? (y or n)».
Only those users with full accounts are able to leave comments. Log in, please.