The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Релиз распределенной системы управления исходными текстами G..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от opennews (??) on 01-Окт-11, 23:22 
Представлен (https://lkml.org/lkml/2011/9/30/406) релиз распределенной системы управления исходными текстами Git 1.7.7 (http://git-scm.com/). Из-за недоступности инфраструктуры kernel.org, код нового релиза временно размещен (https://code.google.com/p/git-core/) на хостинге Google Code, копия создана на SourceForge (http://sourceforge.net/projects/git-core) и GitHub (https://github.com/gitster/git). В качестве подтверждения, что релиз не подделка, мэйнтейнер проекта Junio C Hamano указал на необходимость проверки цифровой подписи.


Некоторые изменения:


-  Скрипты подготовлены для интернационализации и локализации (i18n/l10n);
-  Обновлены порты для Interix, Cygwin и Minix;
-  Разнообразные обновления для git-p4 (в contrib/), fast-import и git-svn;
-  Gitweb теперь в первую очередь пытается прочитать файл конфигурации /etc/gitweb-common.conf и уже потом gitweb_config.perl и /etc/gitweb.conf;
-  При выполнении команды "git am" (загрузка серии патчей из почтового ящика) в связа...

URL: https://lkml.org/lkml/2011/9/30/406
Новость: http://www.opennet.ru/opennews/art.shtml?num=31912

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

Оглавление

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


1. "Релиз распределенной системы управления исходными текстами G..."  +1 +/
Сообщение от Аноним (??) on 01-Окт-11, 23:22 
> Обновлены порты для Interix, Cygwin и Minix;

Это интересно. Насколько сейчас полноценен гит под вендой?

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

4. "Релиз распределенной системы управления исходными текстами G..."  +1 +/
Сообщение от umbr (ok) on 02-Окт-11, 00:39 
Вполне, юзабелен. Git - он и в Африке Git.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

7. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Аноним (??) on 02-Окт-11, 02:04 
Проблемы с кодировками сущетвуют. Не работает юникод в названии файлов.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

14. "Релиз распределенной системы управления исходными текстами G..."  +1 +/
Сообщение от Аноним (??) on 02-Окт-11, 07:22 
А РаЗнЫе РеГиСтРы в именах файлов работают? А то в *nix можно запросто создать Readme.txt и readme.txt в одной дире, а вот у виндов по этому поводу будет butthurt.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

17. "Релиз распределенной системы управления исходными текстами G..."  +6 +/
Сообщение от Аноним (??) on 02-Окт-11, 10:42 
Гит с этим ничего не может сделать. Вендопроблемы.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

30. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от anonymouse on 02-Окт-11, 21:55 
какие проблемы? ntfs - case sensitive и поддерживает Юникод еще аж с момента своего появления (ой, кажется, это 1993 год, за - ээээ - 11 или 12 лет до гита). Не-не, я очень люблю гит, но вендой я тоже не брезгую
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

103. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Аноним (??) on 04-Окт-11, 16:00 
> какие проблемы? ntfs - case sensitive и поддерживает Юникод еще аж с
> момента своего появления

Да, только по дефолту для виндов Readme.txt и readme.txt - один и тот же файл, а то что оно там в теории может - блин, какой процент юзеров вообще знает как и где это включить? Кроме того это не поддерживается большинством софта привыкшего к нечувствительности регистра. Совсем не факт что виндовые архиваторы правильно поймут наличие в 1 дире Readme.txt и readme.txt наприер.

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

32. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от noname (??) on 02-Окт-11, 22:16 
Нормально. УМВР.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

43. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от soos on 03-Окт-11, 13:49 
Используем более 2х лет. Отлично работает.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

10. "Релиз распределенной системы управления исходными текстами G..."  +1 +/
Сообщение от Аноним (??) on 02-Окт-11, 03:53 
Под win как обычно костыли с каким то окружением.
Hg как бальзам послан был, выручает везде.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Релиз распределенной системы управления исходными текстами G..."  –4 +/
Сообщение от добрый дядя on 02-Окт-11, 04:00 
все-таки Mercurial умеет все то же самое, легко портируется на любую ОС, одинаково развитый GUI под все ОС, прост в использовании и более логичная продуманная архитектура для простого применения

Mercurial == Git++

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

12. "Релиз распределенной системы управления исходными текстами G..."  +5 +/
Сообщение от Владимир (??) on 02-Окт-11, 05:17 
Из вашего сообщения следует, что вы используете исключительно mercurial, с git сталкивались пару раз, и он, в виду опыта работы с hg, не понравился...
Именно так и надо было написать, я не пытаться завуалировать ваше отношение и опыт умными словами.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Релиз распределенной системы управления исходными текстами G..."  +1 +/
Сообщение от Аноним (??) on 02-Окт-11, 06:37 
Из вашего сообщения следует, что вы используете исключительно git, с mercuria сталкивались пару раз, и он, в виду опыта работы с git, не понравился...
Именно так и надо было написать, я не пытаться завуалировать ваше отношение и опыт умными словами.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

15. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Аноним (??) on 02-Окт-11, 07:23 
Сталкивался с обоими, гит показался как-то дружественнее и логичнее. Ы?
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

37. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от develop7 (ok) on 03-Окт-11, 02:06 
Сталкивался с обоими, дружественнее и логичнее оказался mercurial
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

92. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от kshetragia email(ok) on 04-Окт-11, 05:09 
Расскажите это счастливым пользователям subversion.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

102. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Аноним (??) on 04-Окт-11, 15:42 
>Расскажите это счастливым пользователям subversion.

А они когда-нибудь сталкивались с DVCS?
Судя потому, что они все еще пользуются svn, нет.

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

157. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от kshetragia email(ok) on 06-Окт-11, 13:31 
>>Расскажите это счастливым пользователям subversion.
> А они когда-нибудь сталкивались с DVCS?
> Судя потому, что они все еще пользуются svn, нет.

Это был всего лишь тонкий намек на то, что я почему-то после cvs/svn, взяв hg изкаробки, просто сел и работал, почитав 20 минут туториал. Т.к. набор команд и юзкейс если и изменились, то незначительно. С git-ом же после двухдневной е..ли желание связываться пропало начисто. Остальное вы сможете найти в комментариях develop7.

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

159. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от develop7 (ok) on 06-Окт-11, 15:20 
>>>Расскажите это счастливым пользователям subversion.
>> А они когда-нибудь сталкивались с DVCS? Судя потому, что они все еще пользуются svn, нет.
> Это был всего лишь тонкий намек на то, что я почему-то после cvs/svn, взяв hg изкаробки, просто сел и работал, почитав 20 минут туториал.

Всё, ну решительно всё Делают Не Так. Как вас только земля носит, еретики? </irony>

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

167. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от kshetragia email(ok) on 07-Окт-11, 05:42 
:-D
Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

104. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Аноним (??) on 04-Окт-11, 16:04 
> Расскажите это счастливым пользователям subversion.

А некоторые вообще до сих пор с деревянными копьями бегают и счастливы.

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

115. "Релиз распределенной системы управления исходными..."  +/
Сообщение от anonymous (??) on 04-Окт-11, 19:44 
> Расскажите это счастливым пользователям subversion.

ну, вот я был пользователем subversion. никогда она мне не нравилась и не казалась удобной. впрочем, я несчастливый пользователь.

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

33. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от develop7 (ok) on 02-Окт-11, 23:02 
> Из вашего сообщения следует, что вы используете исключительно mercurial, с git сталкивались
> пару раз, и он, в виду опыта работы с hg, не понравился...
> Именно так и надо было написать, я не пытаться завуалировать ваше отношение
> и опыт умными словами.

ну вот взять меня. я переехал на git с subversion. тогда я уже знал о существовании DVCS, их преимущества и в принципе был не против переехать.
Поработал с git полгодика на живом проекте. Потратил тучу времени зря на вкуривание манов и терминологии. Два раза штатными средствами сломал репу, один раз — на гитхабе. Оказалось, что силами казуального юзера (которому некогда мастурбировать^W восхищаться gitом и сутками читать маны) самостоятельно разработать и внедрить workflow, отличный от commit => pull => merge => push, невозможно без отрыва от основной деятельности на срок порядка двух дней. И даже после этого уверенности в том, что оно работает надёжно, нет — постоянно ждёшь подвоха и убиения котяток.

После полугода хождения по этому минному полю очень обрадовался поводу начать использовать mercurial (в новом проект). О чём так и не представилось случая пожалеть с середины 2008. Mercurial понятен интуитивно, не требует знаний о кишках СКВ, встроенный help лаконичен и исчерпывающ для комфортной работы. Плюс расширения.
Искаробочный mercurial практически дублирует (а кое-где (mq, acl) и перекрывает) функционал git. Используя hg-git, вполне себе возможно *прозрачно* работать с репозиториями git (нет, *не* отдельной командой, как git-svn).

Так что лично я не вижу ничего предосудительного в нежелании разбираться в сортах фекалий. Предыдущий комментатор всё правильно сделал.

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

38. "Релиз распределенной системы управления исходными..."  +1 +/
Сообщение от anonymous (??) on 03-Окт-11, 05:36 
я напишу меньше текста. 2.5 года, переехали с свн на гит. проекты от мегабайта исходников и выше. бида — не разу ничего не терялось. зато у пары ключевых девелоперов терялись инеты на два-три дня (ну, так вышло; нет, не индусы). с свн в этом были траблы. с гит — не было. 100% (>15) девелоперов сказали, что гит няша. и что hg (был дан выбор) не рулит — по разным причинам. все остались на гите. такие дела.

я не агитирую. я тупо рассказываю use case. про hg ничего плохого сказать не могу: не юзал. может, оно круче. но порог вхождения для девелоперов оказался меньше в гите.

если чо: от студиохуса за досирак до дядек за 40 лет. вердикт был: гит.

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

40. "Релиз распределенной системы управления исходными..."  +/
Сообщение от KO on 03-Окт-11, 10:42 
>> и что hg (был дан выбор) не рулит — по разным причинам

А хоть одну вменяемую можно привести? И желательно технологическую, а не слюни типа "никто не умел, ну мы и не перешли"

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

48. "Релиз распределенной системы управления исходными..."  +/
Сообщение от anonymous (??) on 03-Окт-11, 17:29 
> А хоть одну вменяемую можно привести?

пожалуйста (гит тоже никто не умел, кстати): оно ТОРМОЗИТ. после гита плакать хочется.

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

55. "Релиз распределенной системы управления исходными..."  +/
Сообщение от develop7 (ok) on 03-Окт-11, 18:17 
>> А хоть одну вменяемую можно привести?
> пожалуйста (гит тоже никто не умел, кстати): оно ТОРМОЗИТ. после гита плакать
> хочется.

ага, помню, жаловался на тормоза один деятель. начали копать — выяснилось, что тормозит не CLI, а redmine с плагином Mercurial. Раскопали плагин — оказалось, что оно вызывает hg с параметром --debug. Который отключает куски, написанные на C. Плохой, негодный mercurial, да.

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

56. "Релиз распределенной системы управления исходными..."  –1 +/
Сообщение от anonymous (??) on 03-Окт-11, 18:21 
cool story, bro! возьми пирожок.
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

77. "Релиз распределенной системы управления исходными..."  +/
Сообщение от develop7 (ok) on 03-Окт-11, 20:01 
> cool story, bro! возьми пирожок.

а вот ещё cool story — http://mac.github.com/ использует http://libgit2.github.com/. вопрос — почему они не используют git cli, «как нааармальные люди», и почему в природе до сих пор нет libgit(1)?

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

57. "Релиз распределенной системы управления исходными..."  +/
Сообщение от ruslan email(??) on 03-Окт-11, 18:57 
Пользуюсь hg (Mercurial) в проекте порядка 1 миллион строк кода, Windows. Заявляю авторитетно - не тормозит.
Также пробовал GIT. Что сказать - хорошая VCS. Нравится концепция, с удовольствием прочитал книгу. Единственное, с Windows плохо дружит: кодировки, EOL, прочее. GUI иногда слетает с ошибками (опять же Windows). Немного раздражает запоминать хэши (хоть и частично), все-таки нумерация коммитов в Mercurial удобнее.
А вообще, Линус Торвальдс очень харизматичный человек. С удовольствием слушаю его интервью, а Git on GoogleTalk - хорошой образец жанра. Он смог убедить многих в том, что использовать его продукт могут только самые умные. Типа, Git - это как скальпель в руке у хирурга. И я не спорю, Git действительно хорош. Но Mercurial чуточку лучше и в этом "чуточку" вся суть. Конечно, это мое субъективное мнение.
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

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

дальше, в принципе, читать не обязательно.

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

59. "Релиз распределенной системы управления исходными..."  +1 +/
Сообщение от develop7 (ok) on 03-Окт-11, 19:09 
> Пользуюсь hg (Mercurial) в проекте порядка 1 миллион строк кода, Windows. Заявляю авторитетно - не тормозит.

этого не может быть. потому что этого не может быть никогда. ясно же выше сказали — тормозит. лично я, конечно, с тормозами не сталкивался, но раз сказали — значит не врут.
> Типа, Git - это как скальпель в руке у хирурга. И я не спорю, Git действительно хорош.

выше нам уже убедительно доказали, что Git — лучшее, что придумало человечество.
> Но Mercurial чуточку лучше и в этом "чуточку" вся суть.

Этого тоже не может быть, потому что см. выше.
> Конечно, это мое субъективное мнение.

ещё бы. вы же смеете усомниться в том, что git — лучшая dvcs
</sarcasm>
> Он смог убедить многих в том, что использовать его продукт могут только самые умные.

кстати да. красиво сыграл на ЧСВ.

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

61. "Релиз распределенной системы управления исходными..."  +/
Сообщение от anonymous (??) on 03-Окт-11, 19:17 
это всё, без сомнения, важно и интересно, но я вот до сих пор не могу понять одной вещи: как у *D*VCS может быть нумерация изменений a-la svn. или её нет (да-да, хэши в гите не просто так сделаны) и она очень криво эмулируется, или это на самом деле не *D*VCS. такие дела.

p.s.: да-да, я знаю про то, что в hg встроен кривучий эмулятор. и это один из примеров того, что авторы hg вообще не понимают, что такое DVCS, как оно должно работать и как это использовать.

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

64. "Релиз распределенной системы управления исходными..."  +/
Сообщение от ruslan email(??) on 03-Окт-11, 19:26 
Нумерация 0,...,n существует только в локальном репозитории и имеет смысл только для него. Она существует как временно дополнение к хэш-ноду (который уникален по всем репозиториям)
Удобно для, так сказать, для "ah hoc" операций над ревизиями - простмотреть историю "от и до", переместить changeset (aka rebase), и прочее.
Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

70. "Релиз распределенной системы управления исходными..."  +/
Сообщение от anonymous (??) on 03-Окт-11, 19:37 
штука в том, что она вовсе смысла не имеет, нигде.
Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

87. "Релиз распределенной системы управления исходными..."  +/
Сообщение от Ruslan email(??) on 03-Окт-11, 21:07 
Может она не "необходима" для полноты алгебры операицй над репозиториями, но это очень удобно, поверьте.
Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

65. "Релиз распределенной системы управления исходными..."  +/
Сообщение от develop7 (ok) on 03-Окт-11, 19:26 
> p.s.: да-да, я знаю про то, что в hg встроен кривучий эмулятор.

если запомнить (вы можете выжечь у себя на руке), что «порядковые номера changesetов — для локального использования», жить становится намного проще.

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

69. "Релиз распределенной системы управления исходными..."  +/
Сообщение от anonymous (??) on 03-Окт-11, 19:36 
> если запомнить (вы можете выжечь у себя на руке), что «порядковые номера
> changesetов — для локального использования», жить становится намного проще.

тут вот какое дело: они не нужны *ни для какого* использования. единственная причина их существования — нежная любовь авторов hg к svn-подобным системам. ну, и традиционная боязнь переучиваться, ведь столько лет до этого жили с красивенькими номерами, а тут вдруг хэши! ужас! паника на корабле! срочно запилить назад номера, пока не случилось Страшное!

вот потому я и говорю, что hg — defective by design. потому что пытается эмулировать не просто ненужные, а вредные фичи.

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

74. "Релиз распределенной системы управления исходными..."  +/
Сообщение от develop7 (ok) on 03-Окт-11, 19:42 
>> если запомнить (вы можете выжечь у себя на руке), что «порядковые номера
>> changesetов — для локального использования», жить становится намного проще.
> ну, и традиционная боязнь переучиваться, ведь столько лет до этого жили с красивенькими номерами, а тут вдруг хэши! ужас! паника на корабле! срочно запилить назад номера, пока не случилось Страшное!

отучайтесь проецировать собственные комплексы на незнакомых людей.
локальные номера ревизий полезны, т.к. ими удобнее оперировать без подглядывания в hg log. ну и приблизительное местоположение новоприбывших коммитов видно с одного взгляда.

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

107. "Релиз распределенной системы управления исходными..."  +/
Сообщение от Аноним (??) on 04-Окт-11, 16:10 
> Пользуюсь hg (Mercurial) в проекте порядка 1 миллион строк кода, Windows. Заявляю
> авторитетно - не тормозит.

Учитывая с какой скоростью работает NTFS - там что угодно "не тормозит", только после ext4 этим пользоваться совершенно невозможно, с души воротит от разницы в скорости, ессно не в пользу винды.

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

105. "Релиз распределенной системы управления исходными..."  +/
Сообщение от Аноним (??) on 04-Окт-11, 16:06 
> пожалуйста (гит тоже никто не умел, кстати): оно ТОРМОЗИТ. после гита плакать хочется.

Ну так питонисты против олдскульных перцев же. Понятно кто зарулит. С закрытыми глазами 100 баксов на олдскульных волков ставлю, они делают "как эффективнее" а не "на питоне".

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

42. "Релиз распределенной системы управления исходными..."  +2 +/
Сообщение от develop7 (ok) on 03-Окт-11, 11:38 
> и что hg (был дан выбор) не рулит —  по разным причинам.

ага, знаем. 95% считают, что если вывод не раскрашен, значит это невозможно. и пофиг, что это включается одной строкой в любом конфиге. тоже мне инженеры.

> про hg ничего плохого сказать не могу: не юзал. может, оно круче. но порог вхождения для девелоперов оказался меньше в гите.

в моём случае порог вхождения оказался ниже с HG. собссно, куда уж ниже — нормально работал уже через день подглядывания в первую попавшуюся шпаргалку. причём ровно столько же mercurial осваивал коллега, который кроме svn вообще ничего в жизни не юзал.

мой вердикт — если в команде нет гуры (или хотя бы опытного юзера) git, непроизводительные потери времени гарантированы чуть менее, чем полностью.

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

62. "Релиз распределенной системы управления исходными..."  +/
Сообщение от anonymous (??) on 03-Окт-11, 19:18 
> мой вердикт — если в команде нет гуры (или хотя бы опытного
> юзера) git, непроизводительные потери времени гарантированы чуть менее, чем полностью.

значит, мы всё сделали не так. потому что гуры не было, а я в процесс не вмешивался вообще.

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

66. "Релиз распределенной системы управления исходными..."  +/
Сообщение от develop7 (ok) on 03-Окт-11, 19:29 
>> мой вердикт — если в команде нет гуры (или хотя бы опытного
>> юзера) git, непроизводительные потери времени гарантированы чуть менее, чем полностью.
> значит, мы всё сделали не так. потому что гуры не было, а  я в процесс не вмешивался вообще.

значит, сотни времени спустили в унитаз. git всегда берёт своё — чаще всего временем и ресурсами на запоминание ненужных протекающих абстракций. впрочем, фанбоям не привыкать.

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

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

(пожимает плечами) я так понимаю, hg впитывают с молоком матери. а ты — крутой телепат и провидец прошлого.

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

79. "Релиз распределенной системы управления исходными..."  +/
Сообщение от develop7 (ok) on 03-Окт-11, 20:04 
>> значит, сотни времени спустили в унитаз.
> (пожимает плечами) я так понимаю, hg впитывают с молоком матери. а ты — крутой телепат и провидец прошлого.

почему с молоком? я после git вкурил hg за один рабочий день. остальные вопросы разрешались максимум однократным чтением hg help.

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

80. "Релиз распределенной системы управления исходными..."  +1 +/
Сообщение от anonymous (??) on 03-Окт-11, 20:05 
> почему с молоком? я после git вкурил hg за один рабочий день.
> остальные вопросы разрешались максимум однократным чтением hg help.

а я — гит вкурил меньше, чем за день. и что это доказывает, кроме того, что мы оба умеем читать?

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

108. "Релиз распределенной системы управления исходными..."  +/
Сообщение от Аноним (??) on 04-Окт-11, 16:13 
> а я — гит вкурил меньше, чем за день. и что это
> доказывает, кроме того, что мы оба умеем читать?

Бывает так что берешь в руку инструмент и он в руке как влитой. Вот git - именно такой инструмент, только для мозгов :). По большому счету я в него вообще почти не вкуривал - посмотрел как им другие пользуются и стал так же. Чего там день делать то?!

Ну единственное что надо забыть всякое барахло типа cvs и svn как страшный сон.

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

113. "Релиз распределенной системы управления исходными..."  +/
Сообщение от anonymous (??) on 04-Окт-11, 19:32 
> Чего там день делать то?!

черри-пики, бисекты, бранчи и прочие вкусные ништяки, которые на svn стараешься юзать только в самом крайнем случае (или их и вовсе нет). плюс — привычка таки читать маны до того, как накосячишь, а не после. %-)

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

16. "Релиз распределенной системы управления исходными..."  +6 +/
Сообщение от anonymous (??) on 02-Окт-11, 10:29 
> Mercurial == Git++

судя по «c++», меркуриал — это перегруженый ненужными фичами, дико тормозной и раздутый git. в принципе, правда, наверное.

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

60. "Релиз распределенной системы управления исходными..."  +/
Сообщение от ruslan email(??) on 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

117. "Релиз распределенной системы управления исходными..."  +/
Сообщение от anonymous (??) on 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?

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

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

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

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

119. "Релиз распределенной системы управления исходными..."  +1 +/
Сообщение от develop7 (ok) on 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....
А вы?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

123. "Релиз распределенной системы управления исходными..."  +/
Сообщение от anonymous (??) on 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.

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

131. "Релиз распределенной системы управления исходными..."  +/
Сообщение от develop7 (ok) on 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 (??) on 05-Окт-11, 20:07 
давай будем считать, что я слил: ты просто не в состоянии, похоже, понять, почему механизмы, а не реализации, зачем это, как и куда. уровень code monkey, увы. в общем-то, ничего плохого, с этим не умирают. впрочем, и не творят.
Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

code monkey cannot into aliases.

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

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

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

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

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

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

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

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

31. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от anonymouse on 02-Окт-11, 21:57 
А ветки в hg уже запилили?
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

34. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от develop7 (ok) on 02-Окт-11, 23:09 
> А ветки в hg уже запилили?

аналогом git branch является hg bookmark, которые включены в ядро c версии 1.8 и поставлялись в виде плагина с версии ~1.2. если же вы про возможность кодить в анально^W огороженной уютненькой пещере, к вашим услугам есть Managed Queues (http://mercurial.selenic.com/wiki/MqExtension) и local branches (http://mercurial.selenic.com/wiki/LocalbranchExtension), также существующие с незапамятных времён.

так что да, запилили. и уже очень давно. если бы вас интересовало реальное положение вещей, вы были бы в курсе.

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

35. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Michael Shigorin email(ok) on 03-Окт-11, 01:32 
> если же вы про возможность кодить в анально^W огороженной уютненькой пещере

Интересно, можно ли иметь сколь-нибудь заметный опыт боевой разработки и писать такое...

Если возможность смены контекстов прикручена через гланды, то ей не пользуются.  Если она составляет половину сущности инструмента, то вдруг быстро оказывается, что многие вещи делаются либо на порядок удобнее (когда приходится), либо вообще делаются (когда иначе можно было обойтись откладыванием временных патчей на полочку, чтоб не заморачиваться с отдельным бранчем).

Потому что в жизни обойтись одним контекстом долго ну никак не выходит.  Даже с cvs.


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

36. "Релиз распределенной системы управления исходными текстами G..."  –1 +/
Сообщение от develop7 (ok) on 03-Окт-11, 01:57 
>> если же вы про возможность кодить в анально^W огороженной уютненькой пещере
> Интересно, можно ли иметь сколь-нибудь заметный опыт боевой разработки и писать такое...

5 лет хватит?

> Если возможность смены контекстов прикручена через гланды, то ей не пользуются.  
> Если она составляет половину сущности инструмента, то вдруг быстро оказывается, что
> многие вещи делаются либо на порядок удобнее (когда приходится), либо вообще
> делаются (когда иначе можно было обойтись откладыванием временных патчей на полочку,
> чтоб не заморачиваться с отдельным бранчем).

Говорите конкретнее, парсер намёков is under maintenance.

Если что, у меня текущий проект под гитом. Так вот переключать бранчи между master и develop чаще двух раз в день оказалось просто-напросто неудобно.

> Потому что в жизни обойтись одним контекстом долго ну никак не выходит.
>  Даже с cvs.

Поэтому, как ни странно, для активной разработки двух веток оказывается проще использовать два каталога в фс. А такую модель поддерживают чуть менее, чем все DVCS. И зачем тогда нужен git?

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

45. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Andrey Mitrofanov on 03-Окт-11, 14:42 
>проще использовать два каталога в фс
>поддерживают чуть менее, чем все DVCS. И зачем тогда нужен git?

"И зачем тогда нужны все остальные DVCS?" //Obvious же fix.

<в танке>Не аргумент.</в>

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

47. "Релиз распределенной системы управления исходными текстами G..."  –1 +/
Сообщение от develop7 (ok) on 03-Окт-11, 15:59 
>>проще использовать два каталога в фс
>>поддерживают чуть менее, чем все DVCS. И зачем тогда нужен git?
> "И зачем тогда нужны все остальные DVCS?" //Obvious же fix.

остальные нужны затем, что они проще/быстрее/удобнее git
> <в танке>Не аргумент.</в>

а ну хорошо

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

50. "Релиз распределенной системы управления исходными..."  +/
Сообщение от anonymous (??) on 03-Окт-11, 17:41 
> Если что, у меня текущий проект под гитом. Так вот переключать бранчи
> между master и develop чаще двух раз в день оказалось просто-напросто
> неудобно.

таки никто не рассказал про alias'ы в sh?

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

51. "Релиз распределенной системы управления исходными..."  +1 +/
Сообщение от Andrey Mitrofanov on 03-Окт-11, 18:06 
>> оказалось просто-напросто неудобно.
> таки никто не рассказал про alias'ы в sh?

Ты ему ещё про алиасы в гите расскажи...

Ртуть работает, ртуть в крови, новость о выходе гита +v0.0.1 вызывает синдром отмены и желание поделиться ощущением неудобства со всеми... блииииин, и под вендой ниработаит нифига... Не-у-дол-но!

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

52. "Релиз распределенной системы управления исходными..."  +/
Сообщение от anonymous (??) on 03-Окт-11, 18:08 
> Ты ему ещё про алиасы в гите расскажи...

нененене, чтение манов с выражением только за деньги. %-)

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

54. "Релиз распределенной системы управления исходными..."  +/
Сообщение от develop7 (ok) on 03-Окт-11, 18:12 
>>> оказалось просто-напросто неудобно.
>> таки никто не рассказал про alias'ы в sh?
> Ты ему ещё про алиасы в гите расскажи...

и про них я тоже прочитал в портянках текста, которые почему-то называют манами git

> Ртуть работает, ртуть в крови, новость о выходе гита +v0.0.1 вызывает синдром
> отмены и желание поделиться ощущением неудобства со всеми... блииииин, и под
> вендой ниработаит нифига... Не-у-дол-но!

кто здесь?

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

53. "Релиз распределенной системы управления исходными..."  +/
Сообщение от develop7 (ok) on 03-Окт-11, 18:11 
>> Если что, у меня текущий проект под гитом. Так вот переключать бранчи
>> между master и develop чаще двух раз в день оказалось просто-напросто
>> неудобно.
> таки никто не рассказал про alias'ы в sh?

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

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

121. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Michael Shigorin email(ok) on 05-Окт-11, 16:57 
>>> если же вы про возможность кодить в анально^W огороженной уютненькой пещере
>> Интересно, можно ли иметь сколь-нибудь заметный опыт боевой разработки
>> и писать такое...
> 5 лет хватит?

Не знаю.  Мне с моими двадцатью такие глупости в голову почему-то не стучались.

>> Если возможность смены контекстов прикручена через гланды, то ей не пользуются.
> Говорите конкретнее, парсер намёков is under maintenance.

Да вот ниже пример, спасибо.

> Если что, у меня текущий проект под гитом. Так вот переключать бранчи
> между master и develop чаще двух раз в день оказалось просто-напросто
> неудобно.

Про git stash точно в курсе? :) (кажется, его тоже уже сделали наконец в hg)

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

И возвращаемся к поднятому выше вопросу про опыт.  Мне вот -- ни разу не проще.  Старею? :)

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

134. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от develop7 (ok) on 05-Окт-11, 20:09 
>>>> если же вы про возможность кодить в анально^W огороженной уютненькой пещере
>>> Интересно, можно ли иметь сколь-нибудь заметный опыт боевой разработки
>>> и писать такое...
>> 5 лет хватит?
> Не знаю.  Мне с моими двадцатью такие глупости в голову почему-то не стучались.

надеюсь, имеет место обычное недоразумение.

>> Если что, у меня текущий проект под гитом. Так вот переключать бранчи между master и develop чаще двух раз в день оказалось просто-напросто неудобно.
> Про git stash точно в курсе? :) (кажется, его тоже уже сделали наконец в hg)

в курсе, спасибо за заботу. в hg stash был с незапамятных времён, но и вас, похоже, реальное положение вещей тоже не интересует.

>>> Потому что в жизни обойтись одним контекстом долго ну никак не выходит.
>> Поэтому, как ни странно, для активной разработки двух веток оказывается проще использовать два каталога в фс.
> И возвращаемся к поднятому выше вопросу про опыт.  Мне вот -- ни разу не проще.  Старею? :)

нет-нет, что вы. как можно. очевидно же, что это я — дебил и неосилятор.

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

154. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Michael Shigorin email(ok) on 05-Окт-11, 23:10 
>>>>> возможность кодить в анально^W огороженной уютненькой пещере

[...]
>> Не знаю.  Мне с моими двадцатью такие глупости в голову почему-то не стучались.
> надеюсь, имеет место обычное недоразумение.

Вот теперь имеет -- поясните, о чём :)

Серьёзно, переключением между контекстами в виде каталогов уже давно был сыт по горло и за такие вот "бранчи" был крайне "признателен" bzr'истам.

А в git stash не хватало как раз чтоб свежесозданное тоже упихивало, и то как раз добавили :) (хотя пока не привык к git stash pop вместо apply, порой накапливались кучки на полочке, которые потом доводилось разгребать -- надо ли иль уже ну его всё, протухло)

>> Про git stash точно в курсе? :) (кажется, его тоже уже сделали наконец в hg)
> в курсе, спасибо за заботу. в hg stash был с незапамятных времён,

ЕМНИП года три-четыре, а это вполне запамятные... ну да абы работало.

> но и вас, похоже, реальное положение вещей тоже не интересует.

Если бы не интересовало, так и не упоминал бы.

PS: Вас git покусал, что ли?  Или код ресетом угробили?  Обычно всё-таки эмоций заслуживают люди, а не байтики.

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

155. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от develop7 (ok) on 05-Окт-11, 23:43 
>>>>>> возможность кодить в анально^W огороженной уютненькой пещере
> [...]
>>> Не знаю.  Мне с моими двадцатью такие глупости в голову почему-то не стучались.
>> надеюсь, имеет место обычное недоразумение.
> Вот теперь имеет -- поясните, о чём :)

я имел в виду, что локальные бранчи не особо и нужны. пишешь фичу? хорошо, а зачем шифроваться? ну выпинал ещё ветку, ну и что?

> Серьёзно, переключением между контекстами в виде каталогов уже давно был сыт по горло и за такие вот "бранчи" был крайне "признателен" bzr'истам.

а мне по итогу понравилось :) на текущем проекте очень удобно. пустил два сервака из разных каталогов и только успевай туда-сюда коммитить. inbefore «вы всё делаете не так»: в master вагон legacy хотфиксов, посему вот так. git flow тут избыточен.

>>> Про git stash точно в курсе? :) (кажется, его тоже уже сделали наконец в hg)
>> в курсе, спасибо за заботу. в hg stash был с незапамятных времён,
> ЕМНИП года три-четыре, а это вполне запамятные... ну да абы работало.

да, извиняюсь. я, конечно же, имел в виду «hg без stash *я* не помню». есть MQ, есть два сторонних расширения.

>> но и вас, похоже, реальное положение вещей тоже не интересует.
> Если бы не интересовало, так и не упоминал бы.

а ну хорошо, извините.

> PS: Вас git покусал, что ли?  Или код ресетом угробили? Обычно всё-таки эмоций заслуживают люди, а не байтики.

однажды срочно-срочно пришлось менять workflow без отрыва от интенсивного кодинга. плюс я тогда только-только начал юзать git (и dvcs). как-то получилось за два дня в топку, но котяток оно того и дело убивало по поводу и без. вроде починил с помощью какой-то матери и насилия над мозгом знакомых гуров, но потом всё равно ожидал подвоха, т.к. было непонятно, почему оно работает. ощущение крайне неприятное, я вам скажу. чтение манов запутывало ситуацию ещё больше, плюс в случае проблем неясно было даже, что гуглить. нащальника, подлец, на github пересадил, а на вопросы по git только и говорил «не знаю, погугли». потом меня за эти два дня ещё и покарали слегка. было неприятно, учитывая то, что я ещё и овертаймил.

когда понадобилось слегка усовершенствовать hg workflow, я почитал про feature branches и внедрил их в течение рабочего дня. попробовал сам, поправил доку в вики, коллеги почитали, сказали «яволь» и начали юзать. ВСЁ.

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

156. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Michael Shigorin email(ok) on 06-Окт-11, 00:37 
>>> надеюсь, имеет место обычное недоразумение.
>> Вот теперь имеет -- поясните, о чём :)
> я имел в виду, что локальные бранчи не особо и нужны.

Вам, может, и не нужны.  А я ими активно пользуюсь.

> пишешь фичу? хорошо, а зачем шифроваться?

В смысле "шифроваться"?  Если разработка не собирается смержиться asap в свой же master или что там за него будет, то можно пушнуть её точно так же на публику.

> ну выпинал ещё ветку, ну и что?

И то, что де-факто образовавшиеся контексты в явном виде же и разделены.

У меня вот прямо сейчас в master-бранче mkimage-profiles.git всё собирается, в другом -- подзаброшенная попытка допинать plymouth, а в текущем крушится и ломается набор шурупов, изначально рассчитывавшихся на случай сборки дистрибутивов -- переделываю на прослойку для сборки ещё и openvz template caches (возможно, там же придётся перелопатить логгинг и шире обобщить применение тегированных скриптовых хуков).  Можно такие пертурбации учинять прям в master, но его тогда не пушнешь.  Можно скопировать всё в сторонку, но в лесу этих сторонок я заблужусь тогда скоро и сравнивать их далеко не так удобно, как git log -p или git diff.

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

Так хохма в том, что если я хочу именно такое устроить, то с гитом и так могу. :)

> inbefore «вы всё делаете не так»: в master вагон legacy хотфиксов, посему
> вот так. git flow тут избыточен.

Ну так это по довольно-таки общепринятой логике не master ни разу, а topic branch под соответствующий старый train.

>> PS: Вас git покусал, что ли?  Или код ресетом угробили? Обычно всё-таки эмоций
>> заслуживают люди, а не байтики.
> однажды срочно-срочно пришлось менять workflow без отрыва от интенсивного кодинга.

Уйй, соболезную.  За такое "обучение" методом швыряния в воду PM'ов надо IMHO пороть (если такой случай был).

> плюс я тогда только-только начал юзать git (и dvcs). как-то получилось за
> два дня в топку, но котяток оно того и дело убивало по поводу и без.

Это всё-таки скорее издержки авральщины.  Хотя конкретно перед git rebase (особенно -i) предпочитаю затарить репозиторий на случай своей же ошибки, поскольку один прецедент был (но там именно я сперва сглупил, а потом погорячился -- наработки ещё можно было вытянуть, хотя и было их не так-то много).

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

Вероятно, тогда погробились ссылки, но остались сами pack'и -- даже git gc штатно даёт пару недель на спохватиться).  Если хотите, пороюсь в запасниках и подброшу ссылки на статьи по такому случаю.

> нащальника, подлец, на github пересадил, а на вопросы по git только и говорил
> «не знаю, погугли». потом меня за эти два дня ещё и покарали слегка. было неприятно,
> учитывая то, что я ещё и овертаймил.

У-уу.  За что люблю наших техдира и директора -- _они_ могут показать, как _это_ делается.

Хороший манагер понимает, что он -- бульдозер перед командой, а не крендель с кнутом и пряником.  А очень хороший -- может сделать почти любую работу за тебя, но не будет. :)

> когда понадобилось слегка усовершенствовать hg workflow, я почитал про feature branches
> и внедрил их в течение рабочего дня. попробовал сам, поправил доку
> в вики, коллеги почитали, сказали «яволь» и начали юзать. ВСЁ.

Аврал тоже был или вокруг поспокойней?

PS: спасибо за конструктив, намного толковей обсуждать стало.  И простите, если что не так.

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

158. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от develop7 (ok) on 06-Окт-11, 14:02 
> Ну так это по довольно-таки общепринятой логике не master ни разу, а topic branch под соответствующий старый train.

ок, спасибо за хинт

> Уйй, соболезную.  За такое "обучение" методом швыряния в воду PM'ов надо IMHO пороть (если такой случай был).

тут я солидарен. можно даже бить ногами.

> У-уу.  За что люблю наших техдира и директора -- _они_ могут показать, как _это_ делается.

ну вот. мне так не повезло.

> Хороший манагер понимает, что он -- бульдозер перед командой, а не крендель с кнутом и пряником.  А очень хороший -- может сделать почти любую работу за тебя, но не будет. :)

да.

> Аврал тоже был или вокруг поспокойней?

немного спокойнее. но пары лишних дней не было.
так что я ещё неделю ходил под впечатлением. потому что ожидал потерять впустую минимум пару дней.

> PS: спасибо за конструктив

я старался начинать с конструктивных замечаний, честно.

> И простите, если что не так.

взаимно

Итого: git для меня — источник непредвиденных рисков. Поэтому я его стараюсь не использовать. Лучше hg. Hg-git, на худой конец.

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

99. "Релиз распределенной системы управления исходными текстами G..."  +1 +/
Сообщение от Аноним (??) on 04-Окт-11, 15:30 
>Mercurial == Git++

И это написал программист?
Тут дословно написано Mercurial тождественно равен Гиту до его увеличения.
Проверка:
Git = 1
Mercurial = Git++
print Mercurial
>1

print Git
>2

Не знаю, как сам Mercurial, но программисты ее используют плохие.

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

114. "Релиз распределенной системы управления исходными..."  +1 +/
Сообщение от anonymous (??) on 04-Окт-11, 19:37 
> Не знаю, как сам Mercurial, но программисты ее используют плохие.

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

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

18. "Релиз распределенной системы управления исходными текстами G..."  –4 +/
Сообщение от Сергей (??) on 02-Окт-11, 11:03 
Отлично. На самом деле сейчас git - единственная VCS.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Релиз распределенной системы управления исходными текстами G..."  +3 +/
Сообщение от Онаним on 02-Окт-11, 12:08 
> В "git stash" добавлена опция "--include-untracked";

Вот этому очень рад

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

21. "Релиз распределенной системы управления исходными текстами G..."  –1 +/
Сообщение от Аноним (??) on 02-Окт-11, 13:04 
Когда под Windows уже будет стабильный GUI?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Релиз распределенной системы управления исходными текстами G..."  +2 +/
Сообщение от Аноним (??) on 02-Окт-11, 14:33 
Какое ещё GUI для VCS? Для rm или cat вам GUI не хочется часом?
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

25. "Релиз распределенной системы управления исходными текстами G..."  –2 +/
Сообщение от Guest (??) on 02-Окт-11, 15:14 
> Какое ещё GUI для VCS? Для rm или cat вам GUI не
> хочется часом?

Да, нормальным людям необходим гуй для rm и cat, называется "файловый менеджер".

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

168. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Аноним (??) on 10-Ноя-11, 23:44 
> Да, нормальным людям необходим гуй для rm и cat, называется "файловый менеджер".

А потом оказывается что автоматизировать rm можно лишь посадив обезьяну нажимать кнопочки гляда на часы :)))


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

24. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Guest (??) on 02-Окт-11, 15:12 
> Когда под Windows уже будет стабильный GUI?

А чем git extensions не нравятся?

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

29. "Релиз распределенной системы управления исходными текстами G..."  +1 +/
Сообщение от Аноним (??) on 02-Окт-11, 20:18 
>Когда под Windows уже будет стабильный GUI?

Чтобы юзать GIT на полную силу Windows не годится (как вариант - можно костылями обложить все в округе и ритуально (и с бубнами) эти костыли использовать)...но нахрена?

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

44. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от добрый дядя on 03-Окт-11, 14:20 
нет, я очень длительное время работал с git, пока не пришел к выводу что Mercurial это следующее поколение DVCS - в разы (!) проще по всем пунктам, имеет развитое GUI под все (!) ОС в виде TortoiseHG (сейчас 2.1.3), логичную архитектуру коммитов/веток/меток и всего что угодно

hg подходит для командной разработки и в нем можно выделывать такие вещи, которые с git буду возможны только после длительного мучительного изучения

согласен с пользователем develop7, я, как и он, прошел такую же долгую и мучительную стадию из попыток внедрить git - просто не подходит ни по GUI ни по простоте работы

с hg я легко сделал то, о чем с git я и не мечтал разобраться, потому что с git тупо не работает - то одна особенность, то другой ньюанс, то там сложность
а в hg берешь и все работает

пока не попробуешь - НЕ ПОВЕРИШЬ
стал бы я так нахваливать hg просто так? ведь это открытый проект и никому денег за него не идет

> Из вашего сообщения следует, что вы используете исключительно mercurial, с git сталкивались пару раз, и он, в виду опыта работы с hg, не понравился...

Именно так и надо было написать, я не пытаться завуалировать ваше отношение и опыт умными словами.

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

89. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Аноним (??) on 03-Окт-11, 23:45 
Да да мы поняли что вам нужен красивый Gui.


Ох уж эти "программисты мышкой"

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

91. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Аноним (??) on 04-Окт-11, 02:41 
>нет, я очень длительное время работал с git, пока не пришел к выводу что Mercurial это
>следующее поколение DVCS - в разы (!) проще по всем пунктам, имеет развитое GUI под все
>(!) ОС в виде TortoiseHG (сейчас 2.1.3), логичную архитектуру коммитов/веток/меток и
>всего что угодно
>hg подходит для ...

Git подходит для всего и даже больше. А когда я был "нубом" - я юзал Windows и TortoiseGit (http://code.google.com/p/tortoisegit/ ), так как не сильно понимал философию Git и не знал "родные" тулзы Git'а (да и уровень скилла осилятора был слабоват). И, кстати, да, еще писал много букв...

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

90. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Аноним (??) on 03-Окт-11, 23:51 
Забавно что на гитхабе больше проектов чем всего программистов использующих HG, но последнии все доказывают какой он хороший и какой у него красивый гуй под виндовс(кстати полупрограчный Аэро стили поддерживает? А то, ведь, без полупрозрачных  градиентов никак нельзя использовать).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

93. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Аноним (??) on 04-Окт-11, 07:53 
А в это время BitBucket переходит на гит http://blog.bitbucket.org/2011/10/03/bitbucket-now-rocks-git...
С учетом того что гит теперь поддерживает и Google Code, похоже изделие на питоне никому отдельно не надо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

94. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от develop7 (ok) on 04-Окт-11, 09:08 
> А в это время BitBucket переходит на гит http://blog.bitbucket.org/2011/10/03/bitbucket-now-rocks-git/

ну, если хайп (аналогичный хайпу вокруг nodejs) невозможно обуздать, то можно хотя бы попробовать нажиться на хомячках

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

95. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Федр on 04-Окт-11, 09:45 
>ну, если хайп (аналогичный хайпу вокруг nodejs) невозможно обуздать, то можно хотя бы попробовать нажиться на хомячках
>хайп

Что за смесь нижегородского с французским?
Есть же простое слово для описания таких вещей - "прогресс".

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

98. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от develop7 (ok) on 04-Окт-11, 12:15 
>>ну, если хайп (аналогичный хайпу вокруг nodejs) невозможно обуздать, то можно хотя бы попробовать нажиться на хомячках
>>хайп
> Что за смесь нижегородского с французским?
> Есть же простое слово для описания таких вещей - "прогресс".

http://translate.google.com/#en|ru|hype как бэ намекаэ

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

100. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Аноним (??) on 04-Окт-11, 15:32 
Ожегов и Розенталь вам тоже намекали. Но видимо их намеки пропали даром.


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

101. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от develop7 (ok) on 04-Окт-11, 15:38 
> Ожегов и Розенталь вам тоже намекали. Но видимо их намеки пропали даром.

а я намекал, что hype какбэ ниразу не переводится словом «прогресс».

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

110. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Аноним (??) on 04-Окт-11, 16:34 
> а я намекал, что hype какбэ ниразу не переводится словом «прогресс».

Git просто удобный и быстрый и несложен в освоении. Этого достаточно для популярности у тех кто снабжен мозгом, т.е. разработчиков. Торвальдс вообще молодец, умеет сделать вещь которая потом окажется нужна толпе народа. Он не шарахается между модными трендами и супер-языками, он на результат ориентируется. Что воздается отличным результатом.

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

112. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от develop7 (ok) on 04-Окт-11, 17:06 
>> а я намекал, что hype какбэ ниразу не переводится словом «прогресс».
> Mercurial просто удобный и быстрый и несложен в освоении. Этого достаточно для популярности у тех кто снабжен мозгом, т.е. разработчиков.

obvious fix
а вообще вы говорите так, будто вышеприведённые определения не касаются mercurial.

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

97. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Guest (??) on 04-Окт-11, 11:20 
> А в это время BitBucket переходит на гит http://blog.bitbucket.org/2011/10/03/bitbucket-now-rocks-git...

Никуда он не переходит, учимся читать.

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

111. "Релиз распределенной системы управления исходными текстами G..."  +/
Сообщение от Аноним (??) on 04-Окт-11, 16:35 
> Никуда он не переходит, учимся читать.

Тем хуже для них, имхо.

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

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

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




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

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