The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз распределенной системы управления исходными текстами G..., opennews (??), 01-Окт-11, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


60. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от ruslanemail (??), 03-Окт-11, 19:12 
Выбор чаще диктуется подсознательными стереотипами, чем чистым анализом.
Python - медленно
C/C++ - быстро
На этом основан настоящий холивар Git vs Mercurial. Также как раньше говорили: "Настоящие программисты не пишут на Pascal", можно перефразировать: "От VCS, написанной на Python, ничего хорошего ждать нельзя".
Лично мне нравятся обе системы с перевесом в Mercurial (нативная поддержка веб, расщиряемость, настоящая кросплатформенность).

И еще мне немного обидно за Mercurial, Линус все время пытается сделать вид, что его нет. Даже по версии Linux Journal (2010):
1. Git
2. SVN
3. CVS
4. Mercurial
(no comments)

Ответить | Правка | Наверх | Cообщить модератору

63. "Релиз распределенной системы управления исходными..."  –1 +/–
Сообщение от anonymous (??), 03-Окт-11, 19:20 
> Линус все время пытается сделать вид, что его нет

всё проще: hg просто defective by design. вот и всё.

Ответить | Правка | Наверх | Cообщить модератору

67. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от ruslanemail (??), 03-Окт-11, 19:33 
Git и Mercurial имеют очень похожую архитектуру (design). Различия в основном в несущественных деталах и в инструментах реализации (преславутый C vs Python).
Кстати, концепция очень хорошо (почти математически) описана в книше "Version Control with Git".
Ответить | Правка | Наверх | Cообщить модератору

73. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от anonymous (??), 03-Окт-11, 19:40 
> Git и Mercurial имеют очень похожую архитектуру (design).

дьявол, как обычно, в мелочах. а так — все dvcs более или менее похожи, потому что делают одно и то же.

Ответить | Правка | Наверх | Cообщить модератору

68. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от develop7 (ok), 03-Окт-11, 19:35 
>> Линус все время пытается сделать вид, что его нет
> всё проще: hg просто defective by design. вот и всё.

ага. и вовсе это никакой не butthurt. нисколечко.

олсо про defective design кто бы говорил. даже mercurial с bzr гораздо более unix-way, чем кучка скриптов, которая по странному капризу Линуса справляется с функциями системы контроля версий.

Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

72. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от anonymous (??), 03-Окт-11, 19:39 
> ага. и вовсе это никакой не butthurt. нисколечко.

неа. просто попытка понять марсиан на костылях.

Ответить | Правка | Наверх | Cообщить модератору

75. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от develop7 (ok), 03-Окт-11, 19:50 
>> ага. и вовсе это никакой не butthurt. нисколечко.
> неа. просто попытка понять марсиан на костылях.

не знаю, что вы там пытались сделать. git на мой взгляд — такая же злая шутка марсиан, как C++.
и да, по поводу git недоunixway возражений нет?

Ответить | Правка | Наверх | Cообщить модератору

76. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от anonymous (??), 03-Окт-11, 19:59 
> и да, по поводу git недоunixway возражений нет?

а я не фанат «юниксвея во все поля». в случае с гитом меня вполне устраивает как есть. заметь, что про «юниксвэй» по отношению к hg я тоже не говорил. и вовсе не потому, что «гит не юниксвэен», а потому, что это совершенно не важно. честно — никогда не читал исходники гита. и не читал бы исходники hg точно так же. и там, и там есть коммит-хуки и прочие ништяки (ведь в hg есть?), этого достаточно.

Ответить | Правка | Наверх | Cообщить модератору

109. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от Аноним (-), 04-Окт-11, 16:16 
Да вообще-то гит прямо инкарнация юниксвея: кучка супербыстрых утилит связаны скриптовым glue code. Куда уж юниксвейнее?!?
Ответить | Правка | Наверх | Cообщить модератору

116. "Релиз распределенной системы управления исходными..."  +1 +/–
Сообщение от develop7 (ok), 05-Окт-11, 14:24 
> Да вообще-то гит прямо инкарнация юниксвея: кучка супербыстрых утилит связаны скриптовым  glue code. Куда уж юниксвейнее?!?

Вообще-то есть куда.
юниксвейнее — это наваять libgit, биндинги к ней и кучку фронтендов на любой вкус. даже у гонимого здесь subversion такая архитектура. отчего оно и прикручивается к любой софтине с полпинка. в отличие от кучек скриптов на си с перлом.
Кстати, наличие в природе libgit2 (которую разрабатывают ребята с github) какбэ намекает.
юниксвейнее — это не гадить в консоль после каждого коммита.
юниксвейнее было бы, если бы хотя бы один workflow scenario обходился голыми командами (без ключей).
юниксвейнее было бы, если бы эти утилиты были предназначены для пользователя, а не для собственных нужд. проверочный вопрос — как давно вы запускали git upload-pack?

Учите матчасть.

Ответить | Правка | Наверх | Cообщить модератору

117. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от anonymous (??), 05-Окт-11, 16:15 
> юниксвейнее — это наваять libgit, биндинги к ней и кучку фронтендов на
> любой вкус.

вперёд, чо.

> отчего оно
> и прикручивается к любой софтине с полпинка. в отличие от кучек
> скриптов на си с перлом.

вот странно: у всех прикручивается, даже гуя спокойно используют, а у develop7 не прикручивается. весь строй не в ногу идёт?

> Кстати, наличие в природе libgit2 (которую разрабатывают ребята с github) какбэ намекает.

…на то, что у маководов проблемы с перлом из коробки и вообще с юникс-лайковостью их системы.

> юниксвейнее — это не гадить в консоль после каждого коммита.

ORLY? >/dev/null

> юниксвейнее было бы, если бы хотя бы один workflow scenario обходился голыми
> командами (без ключей).

у нас, в настоящих ос, есть shell aliases. а ещё google://git+aliases сюрпрайз, да?

> юниксвейнее было бы, если бы эти утилиты были предназначены для пользователя, а
> не для собственных нужд.

это как? O_O какого «пользователя»? они предназначены для программистов, которые активно используют DVCS. а тебе обязательно свистелки, перделки и полупрозрачные окна, без этого жизнь не мила? так напиши себе, если время девать некуда. нормальному программисту это не нужно и даже неудобно. а в emacs (и vim тоже, по-моему) git интегрирован вполне нормально.

> проверочный вопрос — как давно вы запускали git upload-pack?

я вот — никогда. ни разу не понадобилось. а тебе понадобилось? зачем?

> Учите матчасть.

вот именно. «чем кумушек считать, рядиться…»

Ответить | Правка | Наверх | Cообщить модератору

119. "Релиз распределенной системы управления исходными..."  +1 +/–
Сообщение от develop7 (ok), 05-Окт-11, 16:42 
>> юниксвейнее — это наваять libgit, биндинги к ней и кучку фронтендов на любой вкус.
> вперёд, чо.

а вот и «это не нужно». но фанбой здесь по-прежнему я, угу.

>> отчего оно и прикручивается к любой софтине с полпинка. в отличие от кучек скриптов на си с перлом.
> вот странно: у всех прикручивается, даже гуя спокойно используют, а у develop7 не прикручивается. весь строй не в ногу идёт?

будете писать UI к git сами — обязательно расскажите, как круто и реюзабельно парсить регэкспами stdout git.

>> Кстати, наличие в природе libgit2 (которую разрабатывают ребята с github) какбэ намекает.
> …на то, что у маководов проблемы с перлом из коробки и вообще с юникс-лайковостью их системы.

вообще-то для libgit2 есть 100500 биндингов. когда как для "github for mac" нужен только один. что какбэ намекаэ.
и вообще, libgit2 писался для собственных нужд. потому, что ванильный git непригоден для использования на серверах — слишком большой оверхед.

>> юниксвейнее — это не гадить в консоль после каждого коммита.
> ORLY? >/dev/null

во-первых,
> Правило тишины: Если программе нечего сказать, пусть лучше молчит.

Mercurial после commit молчит. Bzr молчит. git — гадит.
Также почему-то вспоминается старый советский анекдот:
— (в магазине) А почему дуршлаг без дырок?!
— Сам пробьёшь, небось руки не отвалятся!

>> юниксвейнее было бы, если бы хотя бы один workflow scenario обходился голыми командами (без ключей).
> у нас, в настоящих ос, есть shell aliases. а ещё google://git+aliases сюрпрайз, да?

дуршлаг без дырок

>> юниксвейнее было бы, если бы эти утилиты были предназначены для пользователя, а не для собственных нужд.
> это как? O_O какого «пользователя»? они предназначены для программистов, которые активно используют DVCS. а тебе обязательно свистелки, перделки и полупрозрачные окна, без этого жизнь не мила? так напиши себе, если время девать некуда. нормальному программисту это не нужно и даже неудобно. а в emacs (и vim тоже, по-моему) git интегрирован вполне нормально.

отучайтесь переносить собственные комплексы на незнакомых людей. что, программист — уже не пользователь? и меня, мягко говоря, смущает 120 команд, из которых максимум четверть в состоянии сделать что-то полезное самостоятельно, без скармливания им в stdin сотен недокументированных данных.

>> проверочный вопрос — как давно вы запускали git upload-pack?
> я вот — никогда. ни разу не понадобилось. а тебе понадобилось? зачем?

и я никогда. а команда есть. а зачем она юзеру?

>> Учите матчасть.
> вот именно. «чем кумушек считать, рядиться…»

я опираюсь на определение UNIX way Эрика Реймонда — http://ru.wikipedia.org/wiki/UNIX_way#.D0.A0.D0.B5.D0.B9.D0....
А вы?

Ответить | Правка | Наверх | Cообщить модератору

120. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от Michael Shigorinemail (ok), 05-Окт-11, 16:46 
> я опираюсь на определение UNIX way Эрика Реймонда

А мы -- на здравый смысл.  Реймонд, видите ли, не пророк, да и UNIX way -- не жупел, а хорошо проработанный и доказавший свою полезность подход; что не даёт поводов ставить его на пьедестал.

Ответить | Правка | Наверх | Cообщить модератору

122. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от develop7 (ok), 05-Окт-11, 16:59 
>> я опираюсь на определение UNIX way Эрика Реймонда
> А мы -- на здравый смысл.  Реймонд, видите ли, не пророк, да и UNIX way -- не жупел, а хорошо проработанный и доказавший свою полезность подход; что не даёт поводов ставить его на пьедестал.

не пророк. он «всего лишь» намного более опытный программист.

И мне по-прежнему непонятно, зачем git commit говорит в stdout вот такое вот:

>[master (root-commit) e7a6196] qwe
> 0 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 a

Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

125. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от anonymous (??), 05-Окт-11, 17:02 
> не пророк. он «всего лишь» намного более опытный программист.

и что? есть подозрение, что у тебя ГСМ. собственно, слово «подозрение» я тут вставил чисто из вежливости.

> И мне по-прежнему непонятно, зачем git commit говорит в stdout вот такое
> вот:

не нравится — отключи.

Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

127. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от Andrey Mitrofanov (?), 05-Окт-11, 17:32 
>у тебя ГСМ

Горюче-смазосные? Марш перечитывать Луркоморье! :))

Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

128. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от anonymous (??), 05-Окт-11, 17:36 
>>у тебя ГСМ
> Горюче-смазосные? Марш перечитывать Луркоморье! :))

вообще-то — если не ошибаюсь — термин придумал Луговский, задолго до этого вашего уютненького.

Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

129. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от Andrey Mitrofanov (?), 05-Окт-11, 17:40 
При чём тут "придумал"? Википедия с Гуглем тоже терминов не выдумывают--- Если бы это чему мешало...
Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

123. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от anonymous (??), 05-Окт-11, 16:59 
> а вот и «это не нужно». но фанбой здесь по-прежнему я, угу.

скажи, где тебе так травмировали мозг, что предложение написать (это ж ты страдаешь без 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.

Ответить | Правка | Наверх | Cообщить модератору

131. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от develop7 (ok), 05-Окт-11, 20:00 
>> а вот и «это не нужно». но фанбой здесь по-прежнему я, угу.
> скажи, где тебе так травмировали мозг, что предложение написать (это ж ты страдаешь без 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?

Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

133. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от anonymous (??), 05-Окт-11, 20:07 
давай будем считать, что я слил: ты просто не в состоянии, похоже, понять, почему механизмы, а не реализации, зачем это, как и куда. уровень code monkey, увы. в общем-то, ничего плохого, с этим не умирают. впрочем, и не творят.
Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

135. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от develop7 (ok), 05-Окт-11, 20:34 
а зачем сразу в кусты? если вы правы и понимаете, почему, то вам не должно составить труда изложить вашу точку зрения словами.
Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

137. "Релиз распределенной системы управления исходными..."  +1 +/–
Сообщение от develop7 (ok), 05-Окт-11, 20:46 
> впрочем, и не творят.

А, так вы целый Творец? Чорт, я польщён. Внукам буду рассказывать, что пересекался с настоящим Творцом От Программирования.

Так это, я не пойму, почему вы уходите? Уже вроде и конкретизировал вопросы с претензиями по самое никуда, приготовился Познать Истину — и тут такое. I am disappoint.

Ладно, пойду дальше влачить своё жалкое существование.

Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

152. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от Michael Shigorinemail (ok), 05-Окт-11, 23:00 
> ах ну да, оно же stateful из-за index. тоже, кстати, уродство, но пусть.

/me приготовился выслушать ответ за порожний базар

[skip -- стоны пхпшника про си, типовой набор]

Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

153. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от develop7 (ok), 05-Окт-11, 23:09 
>> ах ну да, оно же stateful из-за index. тоже, кстати, уродство, но пусть.
> /me приготовился выслушать ответ за порожний базар

конкретно этот момент я согласен списать на вкусовщину.

по остальным пунктам есть, что сказать?

Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

118. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от Michael Shigorinemail (ok), 05-Окт-11, 16:38 
> юниксвейнее — это не гадить в консоль после каждого коммита.

В данном разе неудобно, а -q не отменяли.

Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

124. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от develop7 (ok), 05-Окт-11, 17:00 
>> юниксвейнее — это не гадить в консоль после каждого коммита.
> В данном разе неудобно, а -q не отменяли.

дуршлаг без дырок

Ответить | Правка | Наверх | Cообщить модератору

126. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от anonymous (??), 05-Окт-11, 17:04 
>>> юниксвейнее — это не гадить в консоль после каждого коммита.
>> В данном разе неудобно, а -q не отменяли.
> дуршлаг без дырок

code monkey cannot into aliases.

Ответить | Правка | Наверх | Cообщить модератору

130. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от Michael Shigorinemail (ok), 05-Окт-11, 18:27 
>>> юниксвейнее — это не гадить в консоль после каждого коммита.
>> В данном разе неудобно, а -q не отменяли.
> дуршлаг без дырок

Хорошо, давайте переформулирую: в данном случае мне тоже удобней видеть сразу нужное без лишних действий (а докопаться Вы ещё могли к покраске, которую по строго юниксвею строило бы делать каким colorifer, и автопейджеру, потому как надо бы звать руками less -SR).

Можно было бы предъявить дальнейшие контраргументы и продолжать тратить на всё это время, но дискуссия с Вами уже давно явно о вкусах, а они спора не стоят.  Мне вот слакварь не нравится, ну и не ем.

Ответить | Правка | Наверх | Cообщить модератору

132. "Релиз распределенной системы управления исходными..."  +/–
Сообщение от develop7 (ok), 05-Окт-11, 20:04 
>>>> юниксвейнее — это не гадить в консоль после каждого коммита.
>>> В данном разе неудобно, а -q не отменяли.
>> дуршлаг без дырок
> Хорошо, давайте переформулирую: в данном случае мне тоже удобней видеть сразу нужное без лишних действий (а докопаться Вы ещё могли к покраске, которую по строго юниксвею строило бы делать каким colorifer, и автопейджеру, потому как надо бы звать руками less -SR).

ну вот в hg покраска и автопейджер почему-то и сделаны, и по умолчанию отключены (включаются в конфиге). какбэ unixway, причём даже в вашей трактовке.

Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру