Как стать автором
Обновить

Комментарии 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
Блин, картинки не вставляются.
Зачетные картинки! А что за программа?
Смахивает на tortoisehg
Она самая
О, надо поглядеть. Спасибо.
их „продвинутый“ функционал — это тот же самый набор консольных утилит, для которых просто есть кнопочки в интерфейсе
естественно. ведь libgit нет и не предвидится (за исключением dulwich).
А разве в самом git-е внутри не набор гибких низкоуровневых утилит, с помощью которых можно делать с репозиторием что угодно?
Можно-можно. Это если
а) разобраться, что делает каждая из них
б) разобраться, какие команды и в каком порядке вызывать
в) разобраться, почему именно в таком порядке
г) разобраться, что вызывать, если что-то пойдёт не так
д) во всех предыдущих пунктах — курить ключи форматирования вывода на предмет сделать его пригодным для парсинга и парсить-парсить-парсить stdout+stderr. Другого пути нет в принципе (не считая помянутого dulwich).
Inb4: нет, это никакой не unix-way, дорогие фанбойчики. Это самый что ни на есть кровавый enterprise эпохи CP/M и MS-DOS.
В случае с mercurial можно хотя бы на питоне сказать import hg и жонглировать репозиториями в хвост и в гриву. Даже всеми гонимый svn есть фронтенд к libsvn, которую, к слову, и используют всяческие фронтенды (к слову, libчтототам + пачка фронтендов — это и есть unix-way).
НЛО прилетело и опубликовало эту надпись здесь
dulwich не требует установленного git. git-python — требует
JGit
я вот бы с удовольствием послушал рассказ парней из 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?
git checkout PROJECT_NAMEl/*.java

только что сработал
равно как git checkout. для всех файлов
хотя нет, unstage — противоположность add? тогда reset только индексы изменит. да, не приходилось добавлять и удалять много файлов за раз.
не поймите неправильно, мне нравится гит, но хочется его использовать как-то эффективнее что ли, уловить стройность команд и аргументов, как к примеру приходит понимание Perl-а
я с svn загнул потому что в svn вообще нет staging :)
Воспользоваться GUI? :)
да, можно использовать 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) высок. Многие не пользуются ими не потому что думают, что это им не нужно, а потому что это на самом деле сложно. В том числе программисты, которые в большинстве своем тоже люди.

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

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

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

Скрибус, как я понимаю, имеет бинарный формат и потому не прикручивается к системам контроля версий, TeX/LaTeX и сам по себе по юзабилити убойный, а если ещё надо объединить с системой контроля версий, то вообще ппц, неспецы не осилят.
НЛО прилетело и опубликовало эту надпись здесь
> Для коллективного использования есть издательские системы

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

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

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

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

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

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

Или вы ветки/теги создаете, форки и мержи делаете? Ну так либо освойте магию командной строки и силу воображения, либо мучайтесь дальше, Буратино вы наш. Это кунфу отнюдь не для людей, неспособных на что-то более сложное, чем «плагин к эклипсу» (хотя я сам не очень понимаю, зачем все эти сложности вообще нужны).
Вы, видимо, не поняли. С Гитом у меня все прекрасно, я его освоил, именно из командной строки. Но мне не нравится это положение вещей. Или вы из тех, кто считает, что серьезные вещи обязательно должны делаться сложно?
НЛО прилетело и опубликовало эту надпись здесь
Чёрт, среди множества людей, большинство из которых почему-то стремятся к усложнению, очень редко встречаю человека, который стремится к ясности и простоте.
Виват!
git — ясно и просто
минусующих прошу объяснить чем 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 :)
и, на закуску, уже не МОЕ личное мнение — whygitisbetterthanx.com/
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, как обычно). В общем, более общительный инструмент. :)
НЛО прилетело и опубликовало эту надпись здесь
Ну с этим-то никто не спорит (кроме того, что git, в отличие от меркуриала, вроде именно ревизии хранит, а не ченжсеты)
кроме того, что git, в отличие от меркуриала, вроде именно ревизии хранит, а не ченжсеты

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

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

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