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

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

"Язык программирования Go переходит с Mercurial на Git и GitHub"	+/–
Сообщение от opennews (??) on 14-Ноя-14, 09:57
Компания Google объявила (https://groups.google.com/forum/#!topic/golang-dev/sckirqOWepg) о переводе инфраструктуры разработки языка программирования Go на систему управления исходными текстами Git и платформу совместной разработки GitHub. На днях проекту Go исполнилось пять лет, во время основания проекта была выбрана система  Subversion, после чего последовал переход на Perforce, а затем и на Mercurial, из-за необходимости интеграции с существующей системой рецензирования кода. За это время мир изменился и  Git занял прочную позицию лидера. Большинство участников сообщества Go используют Git и GitHub для своего кода. Проблемы с системой рецензирования остались в прошлом, поэтому теперь ничто не сдерживает миграцию проекта на Git. После миграции на Git в качестве системы рецензирования будет использована система Gerrit (http://code.google.com/p/gerrit/), которая уже применяется для кода платформы Android. Миграция на Git начнётся вскоре после релиза 1.4, намеченного на начало декабря. Выпуск 1.5 уже будет сформирован и размещён на GitHub. URL: https://news.ycombinator.com/item?id=8605204 Новость: http://www.opennet.dev/opennews/art.shtml?num=41059
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+7 +/–
Сообщение от Аноним (??) on 14-Ноя-14, 09:57
Вот читал несколько статей о преимуществах других систем над GIT, но кроме каких-то ускоспециализированных вещей вроде, когда нужно еще синхронизировать графику/чертежи и прочую не текстовую ерунду, разумных аргументов не видел. Смысл вообще для новых проектов использовать не GIT?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+2 +/–
	Сообщение от anthonio (ok) on 14-Ноя-14, 10:35
	Поступки, порой, лишены смысла. :-) Но всё-таки. Если, к примеру, провести аналогию с ядром: есть linux, а есть другие *nix подобные ядра. И причины не использовать linux тоже есть.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	8. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–4 +/–
	Сообщение от Аноним (??) on 14-Ноя-14, 10:36
	"Никто не знает гит". В том смысле, что он можный, но понимать - понимают его ой как далеко не все. Получаются ... с гранатой. :(
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	9. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 10:38
	*мощный
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от Аноним (??) on 14-Ноя-14, 10:38
	Так по минимуму его освоить не сложнее чем любую иную VCS, а продвинутости типа мержей и прочего - может делать кто-нибудь относительно вменяемый.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	11. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 10:39
	> Так по минимуму его освоить не сложнее чем любую иную VCS, а > продвинутости типа мержей и прочего - может делать кто-нибудь относительно вменяемый. Ну так мерж, это как бе важная часть даже для базового использования, не? Или что вы имели ввиду?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	15. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+4 +/–
	Сообщение от Какаянахренразница (ok) on 14-Ноя-14, 11:40
	Реально базовое пользование, на мой взгляд, вот такое: * pull * checkout * add * commit * push checkout может быть опциональным. А merge будет делать "специалист".
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	17. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 11:51
	Я имел в виду что мержить может кто-то квалифицированный, а от обезьянок требуется только коммит по большому счету.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	45. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Vkni (ok) on 14-Ноя-14, 16:24
	> Я имел в виду что мержить может кто-то квалифицированный, а от обезьянок требуется только коммит по большому счету. Т.е. Git - переусложнён, раз для базовой функциональности - слияния, требуется "специалист". Merge требуется ведь, если просто ведёшь свою ветку, на которую потом сделаешь pull request.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	54. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от vn971 (ok) on 14-Ноя-14, 22:54
	Я вот видел как-то раз закоммиченные неразрешённые конфликты..)
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	57. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+2 +/–
	Сообщение от Ytch (ok) on 15-Ноя-14, 01:16
	> Т.е. Git - переусложнён, раз для базовой функциональности - слияния, требуется "специалист". Это для слияния в subversion нужен еще какой специалист! Хотя система-то попроще будет.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	63. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от Аноним (??) on 15-Ноя-14, 05:17
	> раз для базовой функциональности - слияния, требуется "специалист" Врядли вы хотите чтобы это вам делали дизайнеры и прочие ГСМщики, которые пару действий заучить еле могут. От таких - только коммиты с материалом, не более. Люди разные бывают... > Merge требуется ведь, если просто ведёшь свою ветку, на которую потом сделаешь pull request. При правильном подходе merge можно вынести на плечи тех кто понимает что он делает. Если обезьянка совсем дерево - вы врядли хотите после такой обезьянки мержи себе в проект. А так git вполне логичная штука. Если не страдать гуманитарным складом ума с полным непониманием рабочих процессов и принятых в распределенных командах подходов.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	70. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–1 +/–
	Сообщение от Vkni (ok) on 15-Ноя-14, 06:24
	> При правильном подходе merge можно вынести на плечи тех кто понимает что > он делает. Если обезьянка совсем дерево - вы врядли хотите после > такой обезьянки мержи себе в проект. Merge - это часто требуемая на местах функциональность, которую невозможно "переложить на плечи специалиста". Например, merge нужен для того, чтобы синхронизировать свою ветку, которую ведёшь отдельно, с github'овским master'ом. Т.е. либо git clone ... и ручное внесение своих изменений, либо merge. Чтобы было проще, синхронизироваться нужно раз в день-два. А ведение отдельной ветки до pull-request'а - минимум неделя. И что - каждый день звать хозяина github'а с просьбой о помощи? :-)
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	73. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 15-Ноя-14, 14:32
	> Merge - это часто требуемая на местах функциональность, которую невозможно "переложить > на плечи специалиста". Я по прежнему считаю что вы врядли захотите получить результат мержа после дизайнера, манагера-маркетолога и прочих техписов. Которые могут подогнать полезный проекту материал, но напрочь не технари и тем более не программисты. Я полагаю что таким людям лучше не проводить мерж ни в какой системе контроля версий, во избежание факапа лишний раз. > Например, merge нужен для того, чтобы синхронизировать свою ветку, которую ведёшь отдельно, > с github'овским master'ом. Т.е. либо git clone ... и ручное внесение > своих изменений, либо merge. А чем вам не нравится git pull из мастера, если уж оно надо? Мерж потребуется только при конфликтах, а поскольку дизайнеры, техписы, переводчики и прочие манагеры код трогать вообще не должны, конфликт свидетельствует или о каком-то грубом косяке со стороны такого индивида, или о том что PM пролошился и разные люди два раза работали над одним файлом типа рисунка, что заведомо кривая ситуация, иррелевантно к vcs. А в нормальном виде, покуда нет грубых нарушений воркфлоу - такие люди просто не должны налетать на конфликты и нужду мержа. Меньше проблем всем остальным. > Чтобы было проще, синхронизироваться нужно раз в > день-два. А ведение отдельной ветки до pull-request'а - минимум неделя. Дизайнер или техпис врядли сможет сделать мерж нормально. Как операцию. Независимо от VCS. Поэтому этим должны заниматься другие, во избежание. И таким людям кстати совершенно не обязательно синхриться с мастером раз в пять минут - сделали фичу да выкатили пулл реквест. Остальное вообще не их дело. > И что - каждый день звать хозяина github'а с просьбой о помощи? :-) Ну если глупить с организацией воркфлоу - еще и не так можно. Но я думаю что воркфлоу надо строить "с каждого по способностям" и мне кажется наивным уповать на то что переводчик может хорошо сделать мерж и ничего не сломать.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	79. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Vkni (ok) on 15-Ноя-14, 20:59
	> Я по прежнему считаю что вы врядли захотите получить результат мержа после дизайнера, манагера-маркетолога и прочих техписов. А зачем они вообще должны туда лезть-то? Merge должен делать человек, понимающий в предмете в первую очередь. Если это статья - редактирующий статью, если код - редактирующий код. > А чем вам не нравится git pull из мастера, если уж оно надо? Если в мастере произошли изменения в тех же файлах, что ты правил, хочешь-нехочешь, а придётся синхронизировать. Ну и pull-request лучше, всё-таки, делать чистый. > Ну если глупить с организацией воркфлоу - еще и не так можно. Но я думаю что воркфлоу надо строить "с каждого по способностям" и мне кажется наивным уповать на то что переводчик может хорошо сделать мерж и ничего не сломать. Если несколько переводчиков работают над одним текстом, всунутым в VCS, им придётся делать merge. И при этом желательно ничего не ломать.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	83. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 16-Ноя-14, 06:19
	> Merge должен делать человек, понимающий в предмете в первую очередь. Совершенно не обязательно, ибо понимание предмета != умение делать технически сложные и достаточно ответственные операции. Технические умения ГСМщиков обычно "не очень" и с компьютерами они "на Вы". Получать мерж после таких индивидов может быть достаточно чреватой идеей. Хоть я и допускаю мысль что часть из них можно научить этому, это уже достаточно индивидуально. А в случае какого-нибудь дизайнера нужда выполнять мерж вообще означает какой-то факап в рабочем процессе. > Если в мастере произошли изменения в тех же файлах, что ты правил, ...то в случае таких ГСМщиков это обычно означает продолб в рабочем процессе. > Если несколько переводчиков работают над одним текстом, всунутым в VCS, > им придётся делать merge. И при этом желательно ничего не ломать. Если честно, на практике я ни разу не встречал ситуации чтобы несколько переводчиков лопатили 1 файл. Во первых, нормальный переводчик стоит денег и поэтому даже в очень большой и крутой конторе их обычно спасибо если 1-2 человека. В опенсорсных проектах может быть и поболее. А может и не быть. Но тут есть во вторых. Во вторых, обычно работа такого плана разбита на юниты вменяемого размера которые может лопатить по человеку на файл, не задевая друг друга. Так чтобы Войну и Мир сразу двутомником переводили как 1 файл - такого я попросту никогда не видел, так никто не делает. А те кому ну просто крындец как надо много возиться с переводами программ - иногда используют узкоспециализированный онлайн сервис Transifex. Но для большинства случаев это как-то оверкилл.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	56. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от umbr (ok) on 15-Ноя-14, 00:46
	Наверно не мерж, а разруливание конфликтов - так это везде повод для паники.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	64. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от Аноним (??) on 15-Ноя-14, 05:18
	> Наверно не мерж, а разруливание конфликтов - так это везде повод для > паники. А я не знаю почему Vkni возомнил что это в других VCS как-то проще.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	71. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Vkni (ok) on 15-Ноя-14, 06:26
	> Наверно не мерж, а разруливание конфликтов - так это везде повод для > паники. Я неправильно написал: меня возмутил подход "позвать специалиста" и исключение merge из базовой функциональности git (см. комменты выше). Какое может быть "позвать специалиста", если синхронизировать с github'овским мастером нужно раз в день-два, а разрабатывать свою ветку до pull-request'а неделю? :-)
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	74. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 15-Ноя-14, 14:43
	> Я неправильно написал: меня возмутил подход "позвать специалиста" и исключение merge из > базовой функциональности git (см. комменты выше). А мне кажется наивным уповать на то что дизайнер или техпис может сделать мерж правильно и ничего при этом не сломать. Хоть там в какой VCS. Поэтому лучше строить воркфлоу так чтобы это делали иные люди. Которые понимают что это такое и как работает. И вполне можно сделать так что индивиду не придется ничего мержить пока он пилит свою фичу. А если индивид окажется не тyпым в техническом плане - можно обучить его основам и поднять эффективность взаимодействия с оным, aka получив возможность совместно работать над одними и теми же файлами. Но это катит только для текстовых файлов (как вы себе представляете мерж картинки со стороны VCS?) и не со 100% индивидов. > Какое может быть "позвать специалиста", Если человек не может делать мержи - его налет на нужду это делать должен стало быть исключением а не правилом. Это несколько лимитирует возможные воркфлоу но не делает взаимодействие с человеком невозможным. Хоть и может сделать взаимодействие менее приятным чем могло бы быть. > если синхронизировать с github'овским мастером нужно раз в день-два, > а разрабатывать свою ветку до pull-request'а неделю? :-) Не очень понимаю зачем техпису или дизайнеру пашущими над своими файликами надо часто синхриться и тем более что-то мержить. Они по идее вообще ни с кем конфликтовать не должны и если это случается - где-то в воркфлоу порылся нехилый косяк.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	80. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Vkni (ok) on 15-Ноя-14, 21:24
	> И вполне можно сделать так что индивиду не придется ничего мержить пока > он пилит свою фичу. Это желательно. Тем более, что это стандартный алгоритм параллелизации работы (Map-Reduce). > Но это катит только для текстовых файлов (как вы > себе представляете мерж картинки со стороны VCS?) и не со 100% > индивидов. Тут хорошая тема поднимается - как делать VCS для нетекстовых данных. Кстати, это не сделано ли во всяких Google Docs? > Если человек не может делать мержи - его налет на нужду это > делать должен стало быть исключением, а не правилом. Угук. Только далеко не всегда это возможно, поэтому исключение очень легко может перетечь в правило. Поэтому merge должен быть как можно сильнее упрощён. > Не очень понимаю зачем техпису или дизайнеру пашущими над своими файликами Если процесс сделан так, то git pull сделает всё сам. Это - идеал, но не всегда возможный идеал.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	84. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 16-Ноя-14, 06:39
	> Это желательно. Тем более, что это стандартный алгоритм параллелизации работы (Map-Reduce). На самом деле очень зависит от людей и того над чем они работают. Поэтому каких-то абсолютно универсальных рецептов не бывает. У нормальных проектов есть некий запас гибкости для того чтобы провзаимодействовать с неким ценным кадром, желательно как можно меньше напрягая остальных. Собственно, хороший руководитель проекта кроме всего прочего может такие вещи утрясти до формата когда процесс идет, явных продолбов не случается и команда не исходит на мат от кривых инструментов и подходов. > Тут хорошая тема поднимается - как делать VCS для нетекстовых данных. Ну да, это довольно отдельная тема. И я не уверен что отложенное совместное редактирование например картинок вообще эффективно. Вот толпой отредактировать картинку в реалтайм - может и прокатит, но такие процессы имеют свойство скатываться в бардак который очень бесит участников, если индивиды не идеально скоординированны. Проверено на сервисе совместного редактирования текстов. Очень бесит когда кто-то буквально под твоим пером переписывает у тебя текст на полуфразе и ты остаешься в обломе. > Кстати, это не сделано ли во всяких Google Docs? Не знаю, я ими не польуюсь. А что, они умеют мерж допустим картинок из нескольких источников в одну? И как это выглядит? Нет, я понимаю как посчитать бинарный дифф пары битмапов, но он совершенно не обязан оказаться именно тем что все хотели, а как-то более гранулярно выбирать что вот тут мы берем пикселы от Васи, а тут от Пети - выглядит не очень простой в реализации затеей и я что-то не уверен что таким vcs должен заниматься. > перетечь в правило. Поэтому merge должен быть как можно сильнее упрощён. Да там и нет никакой ракетной науки. Просто некоторые ГСМщики настолько "на Вы" с компьютером что будет лучше если они не будут это делать и это будет именно исключением для них. > Если процесс сделан так, то git pull сделает всё сам. Это - > идеал, но не всегда возможный идеал. Ну ок, у меня одна картинка а в мастере другая. При том обе отличаются от общего предка. И чего должен сделать автомат? Врубить AI и вместо участников проекта решить какая же картинка правильная? Ну если там такой крутой AI, может команду уже пора уволить? Если AI может такое решение принять - он пожалуй и картинки нарисовать сможет и код напишет :).
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	59. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от imprtat (ok) on 15-Ноя-14, 01:56
	Как по мне, мердж в гите прост, и уж явно удобнее чем в свн, к примеру. А для тех кто не может осилить набор команд и их параметры есть гуевыые или встроенные в IDE клиенты.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	65. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 15-Ноя-14, 05:19
	> А для тех кто не может осилить набор команд и их параметры ...таким разруливание конфликтов лучше вообще не доверять, для начала. Человек лыка не вяжет, а вы ему ответственную работу?!
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	78. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–2 +/–
	Сообщение от iZEN (ok) on 15-Ноя-14, 16:41
	>> А для тех кто не может осилить набор команд и их параметры > ...таким разруливание конфликтов лучше вообще не доверять, для начала. Человек лыка не > вяжет, а вы ему ответственную работу?! Наверно, в Git и SVN/CVS операция merge — ответственная работа. В hg про merge должен быть в курсе каждый разработчик, который коммитит в центральный репозиторий. Иначе он не сможет запушить свои изменения, конфликтующие с теми, которые уже есть в репозитории и сделаны до него. Для успешного разрешения конфликта в hg нужно воспользоваться операцией merge на месте — провести слияние сначала в локальном репозитории, протестировать слияние, закоммитить, а потом уже пушить результат в центральный репозиторий. То есть понимание работы операции merge является одним из основных особенностей работы в команде с hg. Без этого знания разработчикам на местах делать будет просто нечего — они не смогут обмениваться единым кодом.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	85. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от Аноним (??) on 16-Ноя-14, 06:45
	Знакомьтесь, это - изен. Он сегодня делает то же что и обычно - тормозит и затупляет.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	13. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+6 +/–
	Сообщение от Tav (ok) on 14-Ноя-14, 11:03
	Предпочитать какое-либо решение только потому, что оно является самым популярным (лидирующим) — плохой подход, приводящий к централизации, ослаблению конкуренции и  укреплению монополий, замедлению развития, уменьшению положительной зависимости между популярностью и техническим совершенством (если она вообще есть). Ко всему популярному следует относиться с особым подозрением. Я не говорю, что не надо использовать Гит, но уж точно не надо использовать его только потому, что он популярнее других. И точно не надо использовать Гитхаб, потому что используя его, вы явно содействуете централизации Интернета.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	18. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Xaionaro (ok) on 14-Ноя-14, 12:17
	Со всем согласен кроме: > И точно не надо использовать Гитхаб, потому что используя его, вы явно содействуете централизации Интернета. На мой взгляд, github во многом упрощает жизнь. И по-хорошему проект лучше просто держать сразу в двух местах (на github и на своём локальном сервере).
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	21. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 12:24
	всеобщее клеймение штрихкодами на лбу во многом упрощает жизнь, но почему-то немногим это нравится
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	22. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от Xaionaro (ok) on 14-Ноя-14, 12:27
	Во-первых, и что с того? Как это связано с тем, что написал я? Не нравится — не используй. Но критиковать другого за то, что он продублировал свой проект на GitHub и упростил пользователям проекта жизнь — это уже перебор. Ваши проекты-то никто не заставляет на GitHub переносить? Настривайте сколько угодно remote-ов и делайте с ними что угодно. Во-вторых, мы и так таскаем паспорта. Не особо отличается от штрих-кодов на лбах. SourceForge вы тоже считаете системой штрих-кодов на лбах?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	42. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–1 +/–
	Сообщение от anonymous (??) on 14-Ноя-14, 16:14
	>Во-вторых, мы и так таскаем паспорта. Не особо отличается от штрих-кодов на лбах. Логично. Тогда сделай себе штрихкод на лбу. Это явно удобнее, чем паспорт.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	46. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–1 +/–
	Сообщение от Xaionaro (ok) on 14-Ноя-14, 16:53
	>>Во-вторых, мы и так таскаем паспорта. Не особо отличается от штрих-кодов на лбах. > Логично. Тогда сделай себе штрихкод на лбу. Это явно удобнее, чем паспорт. Не эстетично. И повторюсь: > Как это связано с тем, что написал я? Не нравится — не используй. Мне не нравится штрих-код на лбу. Не буду использовать данную идею.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	52. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–1 +/–
	Сообщение от Vkni (ok) on 14-Ноя-14, 21:30
	> Во-вторых, мы и так таскаем паспорта. Я, лично, хожу с паспортом по СПб крайне редко. Чаще всего, никакого удостоверения личности у меня нет.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	66. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 15-Ноя-14, 05:21
	> удостоверения личности у меня нет. Полисмены just in case будут недовольны и могут при случае задержать до выяснения. Если, конечно, полисмены в обозримом радиусе есть...
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	72. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Vkni (ok) on 15-Ноя-14, 06:33
	> Полисмены just in case будут недовольны и могут при случае задержать до > выяснения. Если, конечно, полисмены в обозримом радиусе есть... Практика показала, что для меня этот случай крайне маловероятен. Машина собьёт скорее.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	75. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 15-Ноя-14, 14:49
	> Практика показала, что для меня этот случай крайне маловероятен. Машина собьёт скорее. Ну и ок :). На самом деле я тоже далеко не всегда беру с собой паспорт по тем же причинам. А желающим вытатуировать штрихкод - с удовольствием поможет скайнет :).
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	35. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноноим on 14-Ноя-14, 14:39
	Сообщество разработчиков Go выбрало наиболее удобное для себя решение. Это выбор не навязанный, а свободный. К монополии такие решения приводить не могут. Никто не запрещает использовать лучшие, по каким-либо параметрам, системы. > И точно не надо использовать Гитхаб, потому что используя его, вы явно содействуете централизации Интернета. Бред. К централизации Интернета это отношения не имеет совершенно. Используя не лучшие решения ты поощряешь посредственность и теряешь в собственной производительности.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	49. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от Аноним (??) on 14-Ноя-14, 17:55
	Ненавязанный, свободный выбор может приводить к монополии. Вот пример: есть две компании с примерно одинаковыми (конкурирующими) продуктами, продающимися, ясен пень, по примерно одинаковым ценам. Внезапно первая компания устраивает демпинг и начинает продавать свой продукт по цене в 10% от предыдущей. Вторая компания теперь а) может порадоваться, что они устроили своим клиентам lock-in, и тем даже теперь невыгодно сменять используемый продукт; вторая компания остается на плаву— нет, погодите, мы же рассматриваем "свободный и ненавязанный выбор", верно? Значит, этот вариант не проходит; б) может потерять всех пользователей, потому что как она упросит платить клиентов за такой же продукт вдесятеро дороже? Выбор-то у клиентов свободный и ненавязанный. Что за этим следует — известно, первая компания останется на рынке в одиночестве и сможет воспользоваться своим новым положением. в) может устроить ответный демпинг. Ну, кто-то не выдержит и разорится первым, а оставшаяся компания — см. выше.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	37. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от jOKer (ok) on 14-Ноя-14, 15:04
	Вот поэтому (а так же и потому что можно держать бесплатно закрытые репы) я и использую bitbacket.org))
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	47. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 16:55
	> bitbucket.org Конечно же :)
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	16. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от develop7 (ok) on 14-Ноя-14, 11:41
	смысл использовать mercurial: * встроенный предохранитель от переписывания опубликованной истории * shared mutable history (в разработке, но пользоваться уже можно) * сам факт того, что разработчики занимаются не только исправлением ошибок и мелкими доводками интерфейса * ну и да, искаробочный плагин версионирования блобов
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	20. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Xaionaro (ok) on 14-Ноя-14, 12:21
	> смысл использовать mercurial: > * встроенный предохранитель от переписывания опубликованной истории Что это такое? Запрет на аналогиню «git push --force» и всякие «git rebase»? Или о чём речь? > * shared mutable history (в разработке, но пользоваться уже можно) Это что-то для избегания ssh+vi? > * сам факт того, что разработчики занимаются не только исправлением ошибок и > мелкими доводками интерфейса В git тоже. Особенно, когда заявили о проблеме производительности на крайне больших деревьях. > * ну и да, искаробочный плагин версионирования блобов Как это работает? Я изменил картинку — что сделает этот plugin?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	38. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+3 +/–
	Сообщение от develop7 (ok) on 14-Ноя-14, 15:26
	>> смысл использовать mercurial: >> * встроенный предохранитель от переписывания опубликованной истории > Что это такое? Запрет на аналогиню «git push --force» и всякие «git rebase»? Или о чём речь? поясню на примере http://www.mail-archive.com/dri-devel@lists.sourceforge... — это когда airlied говорит `git rebase myfeature 123456`, а ему «can't rebase public changesets». а он такой «хмм, а откуда там public changesets?» и смотрит в git log. а в логе и правда чужие коммиты. и он такой «ох ты блин точно, git rebase myfeature 3456789». и всё в порядке, а треда выше по ссылке никогда бы не появилось. >> * shared mutable history (в разработке, но пользоваться уже можно) > Это что-то для избегания ssh+vi? нет. http://mercurial.selenic.com/wiki/ChangesetEvolution >> * сам факт того, что разработчики занимаются не только исправлением ошибок и мелкими доводками интерфейса > В git тоже. Особенно, когда заявили о проблеме производительности на крайне больших  деревьях. собссно junio hamano принимает практически любые патчи, кроме меняющих UX в любую сторону. >> * ну и да, искаробочный плагин версионирования блобов > Как это работает? Я изменил картинку — что сделает этот plugin? запишет картинку в отдельный каталог. а при мерже просто спросит «этот файл поменялся в обоих ветках, который взять» вместо того, чтобы рассчитывать диффы, которые всё равно не имеют смысла.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	48. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–4 +/–
	Сообщение от Xaionaro (ok) on 14-Ноя-14, 16:55
	>>> смысл использовать mercurial: >>> * встроенный предохранитель от переписывания опубликованной истории >> Что это такое? Запрет на аналогиню «git push --force» и всякие «git rebase»? Или о чём речь? > поясню на примере http://www.mail-archive.com/dri-devel@lists.sourceforge... > — это когда airlied говорит `git rebase myfeature 123456`, а ему > «can't rebase public changesets». а он такой «хмм, а откуда там > public changesets?» и смотрит в git log. а в логе и > правда чужие коммиты. и он такой «ох ты блин точно, git > rebase myfeature 3456789». и всё в порядке, а треда выше по > ссылке никогда бы не появилось. Ок, верю, что ему-то это может и надо. >>> * shared mutable history (в разработке, но пользоваться уже можно) >> Это что-то для избегания ssh+vi? > нет. http://mercurial.selenic.com/wiki/ChangesetEvolution Аналогично. >>> * ну и да, искаробочный плагин версионирования блобов >> Как это работает? Я изменил картинку — что сделает этот plugin? > вместо того, чтобы рассчитывать диффы, которые всё равно не имеют смысла. А git рассчитывает diff-ы для бинарных файлов?
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	68. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от Аноним (??) on 15-Ноя-14, 05:49
	> А git рассчитывает diff-ы для бинарных файлов? Дельту он попробует посчитать. Это не текстовый дифф, конечно. Может получиться а может и нет - зависит от устройства файлов. На практике же - я спокойно коммитил пачку графики в гит и никто не жаловался. Просто не надо это делать совсем уж безбашенно. А попытки сделать vcs удобной для невменяемых обезьян - сделают ее неудобной для всех остальных. Чего ради я должен греть мозг вопросами где брать файл? У меня есть рабочее дерево проекта и я разложил файл в правильное место иерархии проекта. Вот там он и должен жить по логике вещей.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	62. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 15-Ноя-14, 02:41
	> ... а при мерже просто спросит «этот файл поменялся в обоих ветках, который взять» вместо того, чтобы рассчитывать диффы это же каким упоротым нужно быть чтобы гнать такой бред
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	67. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от Аноним (??) on 15-Ноя-14, 05:42
	> rebase myfeature 3456789». и всё в порядке, а треда выше по > ссылке никогда бы не появилось. Вообще-то для начала у него там подробно расписан воркфлоу который он хочет видеть и там кроме всего прочего - отсутствие незапланированных приколов когда некто что-то делал с чужим кодом. Вообще, чтобы ребэйзить чужой код - надо страдать конкретным донкихотством и считать себя самым умным на планете. Так что я так подозреваю что то чего ты хочешь - может привести лишь к неудачным воркфлоу, когда некто берет на себя слишком много и делает это тихой сапой. И даже отсутствие потерь истории при этом - не делает сильно лучше, ибо проблема - сам такой воркфлоу, когда Вася зачем-то пускает свои грязные лапы в фичу Пети которую он может быть впервые в жизни видит, что-то с ней делает и прочее. В результате Петя как минимум уже не может отвечать за свою фичу - ее Вася от большого ума перепахал. Без спроса. > собссно junio hamano принимает практически любые патчи, кроме меняющих UX в любую > сторону. "Автомобиль Форд может быть любого цвета, при условии что он черный" :). > поменялся в обоих ветках, который взять» вместо того, чтобы рассчитывать диффы, > которые всё равно не имеют смысла. Дифф может иметь смысл а может не иметь. В рамках проекта удобно универсально работать с проектом в рабочем дереве и не греть себе мозг вопросом "откуда брать файл". Из дерева проекта. Нафиг он мне еще в пяти местах? Поэтому лично я вполне себе коммитил измененную графику в гит, это всех устраивало и размер репы оставался вменяемым. Ну да, лист A4 @ 600DPI коммитить раз в пять минут конечно глупо. Но это про common sense, а не технологии...
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	28. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 13:18
	> * встроенный предохранитель от переписывания опубликованной истории Это вообще как? И почему это - фича? Гит вроде делает логичнее просто некуда - показывает все коммиты которые есть. Что и зачем надо с историей делать? Что еще за предохранители? От чего они предохраняют? Не очень понимаю - ремотный коммит ничего моему коммиту сделать и так не может вроде. От чего предохраняться то?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

2. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–3 +/–
Сообщение от _KUL (ok) on 14-Ноя-14, 09:59
Go, go, go ... А он может так же классно мозг взорвать как и C++? shared_ptr<double> pd; double *p_reg = new double; После чего, следующие строки не одно и тоже! shared_ptr<double> psahred = p_reg; shared_ptr<double> pshared(p_reg); Если нет, то значит от него нельзя получить интеллектуального оргазма и следовательно, язык, он не интересен :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+2 +/–
	Сообщение от тень_pavel_simple on 14-Ноя-14, 10:02
	> Go, go, go ... А он может так же классно мозг взорвать > как и C++? > shared_ptr<double> pd; > double *p_reg = new double; > После чего, следующие строки не одно и тоже! > shared_ptr<double> psahred = p_reg; > shared_ptr<double> pshared(p_reg); > Если нет, то значит от него нельзя получить интеллектуального оргазма и следовательно, > язык, он не интересен :) В гамаке и ластах, да не удобно
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+3 +/–
	Сообщение от Аноним (??) on 14-Ноя-14, 10:03
	Можно и икс себе отрезать. >shared_ptr<double> pd; >double *p_reg = new double; что уж, пиши сразу void *p = (void *)0x1233425; (int)*p = 1; авось повезет
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–1 +/–
	Сообщение от _KUL (ok) on 14-Ноя-14, 10:05
	не, ну вы то ерундо то написали
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 10:20
	это одинаковая ерунда, что в твоем примере, что в моем. Учи c++
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	14. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–1 +/–
	Сообщение от _KUL (ok) on 14-Ноя-14, 11:30
	Ты то пальцем в небо тыкнул, туда байты инта начал загонять, тут понятно что будет бред, а я то говорил к тому, что в плюсах сплошные неявные строгие правила. В данном случае, что должно быть явное оределение.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	26. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–1 +/–
	Сообщение от Michael Shigorin (ok) on 14-Ноя-14, 13:11
	> авось повезет I'm feeling luSegmentation fault
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	12. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+2 +/–
	Сообщение от arsenicum (??) on 14-Ноя-14, 10:54
	Конструктор shared_ptr, который принимает указатель, нужно вызывать явно (explicit). Это является защитным механизмом, чтобы программист понимал, что shared_ptr становится владельцем этого указателя и освободит его сам.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	19. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–1 +/–
	Сообщение от Аноним (??) on 14-Ноя-14, 12:19
	интеллектуального оргазм от с/с++ достигается на таком коде: #ifndef OPENSSL_NO_HEARTBEATS int tls1_process_heartbeat(SSL *s){          unsigned char *p = &s->s3->rrec.data[0], *pl;          unsigned short hbtype;          unsigned int payload;          unsigned int padding = 16; /* Use minimum padding */          /* Read type and payload length first */          hbtype = *p++;          n2s(p, payload);          pl = p; Ручное управление памятью, все дела. Зато быстро.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	69. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 15-Ноя-14, 06:11
	> Ручное управление памятью, все дела. Зато быстро. Сдуру можно и х... сломать. И root cause тут не сишечка, а 1) Переусложненный протокол с кучей легаси и костылей. * Для начала, фича просить у ремоты энное количество байтов - не должна была существовать, даже в проекте. Ну и багов в ней - соответственно, быть не должно. * А вон тут соседняя атака - с буферами ничего не делает вообще. MITM просто даунгрейдит протокол с TLS'а до SSLv3 и потом радостно вскрывает древний и слабый вариант протокола. И ничего вы с этим отказом от управления памятью не сделаете. 2) Как известно, сдуру можно и х... сломать и в криптографии автоматическое управление памятью - последнее что может помочь криптографу. Ключи должны изничтожаться предсказуемо, etc. Без этого будет много неочевидных ламоватым кидизам но от того не менее опасных в плане утечки ключей дыр. Ключ должен существовать ровно столько сколько он требуется и на этом пути GC с отложенной сборкой может очень сильно нагадить. И вообще, идея использовать криптографическую либу от тех кто не может даже памятью управлять - очень сомнительна. А сколько там тогда багов в алгоритмах криптографии и обвязке? 3) У OpenSSL дурное апи и дурной код. Ее авторы вообще не криптографы. Поэтому не так уж принципиально какой ЯП они возьмут. Сильно безопаснее не станет. Наворачивание хитрозадых конструкций на сях лишь немного дополняет эту картину. И не более того. А вовсе и не перекраивает весь ландшафт.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	24. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от Аноним (??) on 14-Ноя-14, 12:47
	Ямщик, не гони. sp_test.cpp: In function ‘int main()’: sp_test.cpp:10:30: error: conversion from ‘double*’ to non-scalar type ‘std::shared_ptr<double>’ requested shared_ptr<double> psahred = p_reg; Конструктор shared_ptr объявлен explicit как раз, чтобы не было неявного преобразования.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	32. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 13:44
	такие вещи надо писать на ржавчине, а не на плюсах :)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	39. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 15:27
	> Go, go, go ... А он может так же классно мозг взорвать как и C++? Это язык для продакшнов, у него задачак как раз не взрывать мозг даже на сложных алгоритмах — всё записывается немногочисленными простыми конструкциями. А для интеллектуальных оргазмов, вперёд в Хаскель (Лисп, Форт, Брайнфак...).
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	60. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 15-Ноя-14, 02:25
	тут никакого взрыва мозга нет.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

23. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
Сообщение от manster (ok) on 14-Ноя-14, 12:36
ещё в одном, отдельно взятом государстве наступил коммунизм...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

25. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
Сообщение от Штунц on 14-Ноя-14, 13:05
А теперь вопрос для размышления: "А ПОЧЕМУ НЕ НА code.google.com ???"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+2 +/–
	Сообщение от vitalif (ok) on 14-Ноя-14, 13:16
	Потому что оно самое неудобное из всех хостингов и, можно сказать, сдохло.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	29. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от агоним on 14-Ноя-14, 13:19
	Вот лишь бы ляпнуть. Как ты думаешь, где он хостился до этого (всё ещё пока хостится)? А таки давно понятны толстые намёки гугла на будущее code.google.com Просто с этой платформой нельзя как со всякими рсс-читалками за пару месяцев закрыть и никаких последствий. Готовят из далека, чтобы адекватные потихоньку оттуда съезжали, а новые проекты даже не думали там заводиться.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	31. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 13:43
	> Готовят из далека, чтобы адекватные потихоньку оттуда съезжали Адекватные для начала там никогда и не будут хоститься - достаточно 1 взглядя на интерфейс. Вообще гугл в отличие от мс хотя-бы умеет признавать что схватился за то что им не свойственно и вышла фигня. А мс до последнего впаривает кривой булшит, типа горбатых кирпичей в восьмерке.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	33. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–2 +/–
	Сообщение от Аноним (??) on 14-Ноя-14, 13:52
	>А мс до последнего впаривает кривой булшит, типа горбатых кирпичей в восьмерке что за горбатые кирпичи? Если речь про плитки, то в десятке они фактически выпилены
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	51. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+3 +/–
	Сообщение от Аноним (??) on 14-Ноя-14, 19:02
	Как сделать хорошо? Просто! Сначала сделай чтоб было хуже, чтоб совсем плохо ... а потом верни всё, как было до этого! :) (C) M$ Business Strategy Manual.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	76. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 15-Ноя-14, 14:56
	> что за горбатые кирпичи? Если речь про плитки, то в десятке они > фактически выпилены Мне если честно уже пофиг - у меня на десктопе и ноуте пингвин и мое DE совершенно не зависит от кучи причуд группы придypков из редмонда. И будет таким какое удобно мне, а не каким-то левым хpeнам.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	34. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 14:12
	Как перенесут leveldb с гугль-кода - значит конец гуглькоду пришел. Для меня такой маркер
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	50. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 18:49
	Ну, значит всё https://code.google.com/p/leveldb/ The LevelDB project has moved to https://github.com/google/leveldb
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	43. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Michael Shigorin (ok) on 14-Ноя-14, 16:19
	> Просто с этой платформой нельзя как со всякими рсс-читалками offtopic: есть отличный проект quiterss, прижился, рекомендую.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	30. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 13:41
	> "А ПОЧЕМУ НЕ НА code.google.com ???" Потому что по сравнению с гитхабом он.. мм... как бы это помягче то, без мата? :)
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	55. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Anonim (??) on 15-Ноя-14, 00:45
	>Потому что по сравнению с гитхабом он.. мм... как бы это помягче то, без мата? :) Эээ... гуёвый?
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	88. "Язык программирования Go переходит с Mercurial на Git и..."	+/–
	Сообщение от arisu (ok) on 16-Ноя-14, 15:05
	>> "А ПОЧЕМУ НЕ НА code.google.com ???" > Потому что по сравнению с гитхабом он.. мм... как бы это помягче > то, без мата? :) ничем особо не отличающийся, кроме количества хипстеров?
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

36. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
Сообщение от Нимо Ан on 14-Ноя-14, 14:58
Судя по актуальным тенденциям Git победил и преступил к перетягиванию всех на себя своей массой (чисто популярностью: "у соседа git - у меня тоже будет git"), теперь контроль версий = git.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 14-Ноя-14, 15:35
	Разве это плохо?
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	41. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–1 +/–
	Сообщение от develop7 (ok) on 14-Ноя-14, 15:58
	плохо ли невежество?
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	44. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Michael Shigorin (ok) on 14-Ноя-14, 16:23
	> плохо ли невежество? Смотря что пытаются им назвать, а что -- представить как "просвещённость".
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	77. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 15-Ноя-14, 15:20
	> плохо ли невежество? Использование гит != невежество. И да, вас не смущает что вы на опеннет должны идти по именно TCP/IP? А то может вам IPX/SPX симпатичнее? И что постить надо по именно протоколу HTTP? А то мало ли, вдруг вам gopher больше нравится? К чему это я? А к тому что в сетях и при взаимодействии с другими людьми придется соблюдать некие форматы и протоколы.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	82. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–2 +/–
	Сообщение от Vkni (ok) on 15-Ноя-14, 21:28
	> Использование гит != невежество. И да, вас не смущает что вы на > опеннет должны идти по именно TCP/IP? А то может вам IPX/SPX > симпатичнее? И что постить надо по именно протоколу HTTP? А то > мало ли, вдруг вам gopher больше нравится? Многим нравится IPv6, но из-за монополии IPv4 переход очень сложен.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	87. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 16-Ноя-14, 07:06
	> Многим нравится IPv6, но из-за монополии IPv4 переход очень сложен. 1) У IPv6 есть навалом своих проблем. В том числе новых и свежих. 2) Если кто хочет IPv6, его можно получить. Может кривовато, но все-таки. 3) А настоящий next gen на самом деле должен выглядеть в первом приближении как-то так: https://en.wikipedia.org/wiki/Cjdns - заметьте, вменяемые люди не уповают ни на кого и делают из того что есть то что хочется. Наиболее практичный подход.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	81. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–1 +/–
	Сообщение от Vkni (ok) on 15-Ноя-14, 21:28
	> Разве это плохо? Плохо.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	86. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (??) on 16-Ноя-14, 07:01
	> Плохо. Не хуже чем необходимость использования IPv4 и HTTP для отправки сообщений на опеннет.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	61. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+3 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 15-Ноя-14, 02:28
	победил как технически более лучшее и удобное решение из доступных альтернатив.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	89. "Язык программирования Go переходит с Mercurial на Git и..."	+/–
	Сообщение от arisu (ok) on 16-Ноя-14, 15:07
	> Судя по актуальным тенденциям Git победил и преступил к перетягиванию всех на > себя своей массой (чисто популярностью: "у соседа git - у меня > тоже будет git"), теперь контроль версий = git. разработчики FreeBSD смотрят на тебя как на говорящего микроба.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

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

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