>> а вот и «это не нужно». но фанбой здесь по-прежнему я, угу.
> скажи, где тебе так травмировали мозг, что предложение написать (это ж ты страдаешь без libgit, а не я — ты и пиши) ты воспринимаешь как «это не нужно»?да не сказать, что так сильно страдаю. за потраченные впустую ресурсы обидно.
>> обязательно расскажите, как круто и реюзабельно парсить регэкспами stdout git.
> вполне нормально.
я про интеграцию git в что-нибудь сложнее шеллскриптов.
>> и вообще, libgit2 писался для собственных нужд. потому, что ванильный git непригоден для использования на серверах — слишком большой оверхед.
> и? понадобилось — написали. в чём, собственно проблема и откуда такой батхёрт? что сразу на тарелочке не выкатили? так не надо было тогда.
да всегда надо было. просто git начинался как фреймворк, а сейчас позиционируется как vcs. вот и торчит легаси изо всех дыр. а хомячки едят да нахваливают.
>> во-первых,
>>> Правило тишины: Если программе нечего сказать, пусть лучше молчит.
> а в данном случае есть что сказать. к тому же я, например, с этим правилом не согласен совершенно, и предпочитаю правило «программа должна отчитываться о том, что делает, а затыкать её можно ключом -q». «правило тишины» пригодно только для самых простых утилит, а git этим не является.
ах ну да, оно же stateful из-за index. тоже, кстати, уродство, но пусть.
но тогда почему оно говорит, какие файлы созданы/удалены, но не говорит, какие изменены? зачем дублирует commit message, которое только что передавалось юзером в ключе -m/набиралось юзером же в редакторе? что пользователь получает от того, что знает хэш только что созданного коммита? для кого вся эта информация?
>> Mercurial после commit молчит. Bzr молчит. git — гадит.
> (пожимает плечами) google://git-alias, исправь. в чём проблема-то? авторы гита (и я тоже) считают, что лучше не молчать.
я про алиасы был в курсе уже на третий день знакомства с git. тогда мне было пофиг. а потом я git не использовал напрямую.
>> дуршлаг без дырок
> а, я понял: ты из противников настроек в программах, всё должно быть «искаропки».
я не против настроек. я против «не работает искаропки». git искаропки и без чтения манов *И* книг вроде «pro git» в поисках ответа на вопросы типа «а почему reset именно --hard? а почему reset, а не checkout?» не работает. плюс марсианская терминология, которую приходится парсить с глоссарием в соседнем окне.
inbefore «я манов не читал»: заучить 5 команд может любой идиот. а вот чтобы использовать их осознанно — приходится хотя бы читать маны. в случае с hg чтения манов достаточно для осознанного использования. в случае с git для этого приходится изучать, что происходит у него в кишках. и это — непроизводительные затраты времени, т.к. в дальнейшем они не окупаются, на мой взгляд.
> небось, Lua и Scheme тоже за языки не считаешь, потому что они предоставляют механизмы, а не реализации.
вообще как-то не задумывался над вопросом «являются ли Lua и Scheme языками». видимо, таки считаю. а с чего вы взяли, что нет?
> это, в принципе, «конфликт» code monkeys и programmers. первые предпочитают, чтобы было как можно больше реализаций, а вторые — чтобы дали простые механизмы для создания своих реализаций.
ахаха. то есть меня вы, очевидно, относите, к первому типу? не стесняйтесь в оскорблениях, прошу вас — это же интернеты, да и вы пишете из-под анонимуса.
> собственно, штришок к портрету типичного пользователя hg.
можно подумать, вы их много видели. inbefore «достаточно»: сколько именно знакомых вам людей используют hg в коммерческих проектах?
как я уже говорил, vcs — *инструмент* управления версиями. использование его прямой прибыли не приносит. следовательно, лучше тот инструмент, который а) меньше мешает работать б) более предсказуем. В моём случае таковым оказался mercurial. Я исхожу из 6 месяцев git, ~года hg и опять 3 мес. использования git в оплачиваемых проектах.
>> отучайтесь переносить собственные комплексы на незнакомых людей. что, программист — уже не пользователь? и меня, мягко говоря, смущает 120 команд, из которых максимум четверть в состоянии сделать что-то полезное самостоятельно, без скармливания им в stdin сотен недокументированных данных.
> см. выше про code monkey vs programmer.
>> и я никогда. а команда есть. а зачем она юзеру?
> «дядя Петя, вы дурак?» (ц) опять code monkey vs programmer.
вы точно понимаете, что вам говорят? попробую переформулировать.
конечный пользователь (*любой*) использует git upload-pack сотоварищи (2/3 команд git) чуть менее, чем никогда. зачем оно тогда болтается в автокомплите и git help? и, что важнее — где, чёрт побери, написано «дорогой новичок, в git 120 команд, 2/3 из которых — для внутреннего использования и не понадобятся тебе вообще никогда; вот их список: [список поскипан]».
>> я опираюсь на определение UNIX way Эрика Реймонда
>> А вы?
> а я — на своё. выразить можно очень просто: важны механизмы, а не реализации. имея нужные механизмы, любую желаемую реализацию можно собрать практически «из кубиков». опять code monkey vs programmer.
похоже, у вас очень много свободного времени, если вы ещё и занимаетесь «собиранием реализаций». но это скорее всего пройдёт.
я не против «собирать из кубиков», отнюдь. но на дворе 2010, а не 1999. зачем «собирать» инструмент, если уже есть готовые и можно *не* собирать? олсо git уже давно не является каркасом VCS.
И всё-таки: какой конкретный профит даёт любому пользователю обилие низкоуровневых команд в git?
