> а вот и «это не нужно». но фанбой здесь по-прежнему я, угу.скажи, где тебе так травмировали мозг, что предложение написать (это ж ты страдаешь без libgit, а не я — ты и пиши) ты воспринимаешь как «это не нужно»?
> будете писать UI к git сами
зачем?
> обязательно расскажите, как круто и
> реюзабельно парсить регэкспами stdout git.
вполне нормально.
> и вообще, libgit2 писался для собственных нужд. потому, что ванильный git непригоден
> для использования на серверах — слишком большой оверхед.
и? понадобилось — написали. в чём, собственно проблема и откуда такой батхёрт? что сразу на тарелочке не выкатили? так не надо было тогда.
> во-первых,
>> Правило тишины: Если программе нечего сказать, пусть лучше молчит.
а в данном случае есть что сказать. к тому же я, например, с этим правилом не согласен совершенно, и предпочитаю правило «программа должна отчитываться о том, что делает, а затыкать её можно ключом -q». «правило тишины» пригодно только для самых простых утилит, а git этим не является.
> Mercurial после commit молчит. Bzr молчит. git — гадит.
(пожимает плечами) google://git-alias, исправь. в чём проблема-то? авторы гита (и я тоже) считают, что лучше не молчать.
> дуршлаг без дырок
а, я понял: ты из противников настроек в программах, всё должно быть «искаропки». небось, Lua и Scheme тоже за языки не считаешь, потому что они предоставляют механизмы, а не реализации. это, в принципе, «конфликт» code monkeys и programmers. первые предпочитают, чтобы было как можно больше реализаций, а вторые — чтобы дали простые механизмы для создания своих реализаций. собственно, штришок к портрету типичного пользователя hg.
> отучайтесь переносить собственные комплексы на незнакомых людей. что, программист —
> уже не пользователь? и меня, мягко говоря, смущает 120 команд, из
> которых максимум четверть в состоянии сделать что-то полезное самостоятельно, без скармливания
> им в stdin сотен недокументированных данных.
см. выше про code monkey vs programmer.
> и я никогда. а команда есть. а зачем она юзеру?
«дядя Петя, вы дурак?» (ц) опять code monkey vs programmer.
> я опираюсь на определение UNIX way Эрика Реймонда
> А вы?
а я — на своё. выразить можно очень просто: важны механизмы, а не реализации. имея нужные механизмы, любую желаемую реализацию можно собрать практически «из кубиков». опять code monkey vs programmer.
