Хостинг свободных проектов GitHub.com (https://github.com/), базирующийся на системе управления исходными текстами Git и позволяющий разработчикам общаться формате единой социальной сети, сообщил (https://github.com/blog/841-those-are-some-big-numbers) о преодолении отметки в два миллиона git-репозиториев. Примечательно, что 70% из всех проектов были созданы в прошлом году. В настоящее время ежедневно в сервисе регистрируется около 4500 проектов. В сервисе зарегистрировано более 700 тысяч разработчиков.
По оценке представителей GitHub в настоящее время около 1.1 млн всех зарегистрированных на сайте проектов являются полными репозиториями. Оставшиеся 900 тысяч репозиториев используются в виде Gist-блоков (http://gist.github.com/), предназначенных для публичного размещения и совместного обсуждения различных заметок и мелких кусков кода, которые сохраняются в отдельных git-репозиториях, что позволяет использовать с ними такие возможности как версионный контроль изменений.С м...
URL: https://github.com/blog/841-those-are-some-big-numbers
Новость: http://www.opennet.me/opennews/art.shtml?num=30318
70% в прошлом году? Попахивает репозитариями-однодневками.
> Попахивает репозитариями-однодневками.Для этого и заточено, намного проще форжа и удобнее:
Оставшиеся 900 тысяч репозиториев используются в виде Gist-блоков, предназначенных для публичного размещения и совместного обсуждения различных заметок и мелких кусков кода
Думаете, того?
Прокладочные структуры для отмывания кода?
> Открытые проекты обслуживаются бесплатно и без ограничений на число проектов и участников разработки.Ну, скажем, это не совсем верно - есть ограничение в 300 MB, что довольно мало для, например, какой-нибудь игрушки с графическими данными, и особенно если хранить историю tarball'ов. Правда, там написано что это soft limit, интересно что будет если его превысить.
А вообще новость радует - хоть это число ни о чём не говорит (проме обычных репозиториев в git хранятся wiki, gist и бог знает что ещё), GitHub, пожалуй, лучший хостинг для свободных проектов на данный момент, и самый динамично развивающийся.
А главное в нём - это поощрение и облегчение совместной разработки - fork + pull request.
А еще есть Perl.
Проекты: Mojolicious, Dancer, PlackНе Руби единым сыты.
> Правда, там написано что это soft limit, интересно что будет если его превысить.придёт администрация и мягко предложит или заплатить, или убираться.
Вообще-то они сами пишут, что это для предотвращения злоупотреблений; а кому надо -- "пишите, порешаем". Чтоб кому-то от них было описанное Вами предложение -- пока не слышал.
> Вообще-то они сами пишут, что это для предотвращения злоупотреблений; а кому надо
> — «пишите, порешаем». Чтоб кому-то от них было описанное Вами
> предложение — пока не слышал.с известными более-менее проектами — порешают. с проектами одного-двух людей — предложат денег дать.
я не говорю, что это плохо, прошу заметить, это вполне логично и оправдано.
Напоминает анекдот- пошел мужик за солью к соседке- постучал, стоит, ждет, и в это время думает - сейчас откроет, пригласит зайти, потом там у нее чай, ну, выпьем, то сё, потом в постель потащит, залетит, вот жениться надо будет, дети пойдут,работать , как волк, приду с работы злой и уставший....она дверь открывает , а он ей говорит - иди ты на х"й со своей солью!Не вы часом? Уж больно ход мысли похож.
тс-с-с. я голодаю.
вот как только они оторвут идиотски-принудительный https — так сразу и станут более-менее вменяемым хостингом.
> вот как только они оторвут идиотски-принудительный https — так сразу и станут более-менее вменяемым хостингом.Это, кстати, тоже офигенная фича. Всё должно быть https.
> Это, кстати, тоже офигенная фича. Всё должно быть https.вот я у них забыл спросить, что у меня должно быть, а что — нет. кто хочет https — пусть использует. а принудительно могут себе его в шоколадный глаз засунуть.
> вот я у них забыл спросить, что у меня должно быть, а
> что — нет. кто хочет https — пусть использует. а принудительно
> могут себе его в шоколадный глаз засунуть.Не-не :) это вы можете засунуть себе в шоколадный глаз свои идиотские требования, а прогрессивное человечество будет работать с репозиторием через безопасное соединение :)))
> Не-не :) это вы можете засунуть себе в шоколадный глаз свои идиотские
> требования, а прогрессивное человечество будет работать с репозиторием через безопасное
> соединение :)))да на здоровье. благо, меня никто не заставляет использовать сервис, который считает, что лучше меня знает, что мне надо. у меня уже операционка была, которая считала, что лучше меня всё знает; к счастью, я лет 10 назад выкинул её в помойку.
ещё раз, на всякий случай: я не говорю, что https надо отключить. я говорю, что не надо его мне принудительно пихать. если я набираю http — я хочу работать по протоколу http. когда я захочу работать по протоколу https — я наберу https. а решать за меня, что я хочу — это туда, в Рэдмонд.
А не пофиг вообще?
Учитывая то, что большая (или даже большая) часть Ruby и Python проектов на github это веб-проекты, то или php совсем уже неинтересен, или средний php-разработчик слыхом не слыхивал ни о каких системах контроля версий.А что на github больше проектов на ruby, чем на python - это логично, github сам написан на ruby. На bitbucket, вероятно, лидер python.
да все знают что гитхаб на Руби написан. Поэтому там и концентрации рубистов высокая.
Только не правильно пишите github это не хостинг свободных репозиториев. 90% в закрытом доступе и никогда не станут "свободными". На то в github и придумана концепция платных юзеров и "организаций".
> Только не правильно пишите github это не хостинг свободных репозиториев. 90% в
> закрытом доступе и никогда не станут "свободными". На то в github
> и придумана концепция платных юзеров и "организаций".Откуда цифирь? Ссылка на источник?
> Только не правильно пишите github это не хостинг свободных репозиториев. 90% в
> закрытом доступе и никогда не станут "свободными". На то в github
> и придумана концепция платных юзеров и "организаций".И что? Концепция организаций к платности вообще отношения не имеет, организацию можно и для свободного проекта запилить. А что до закрытых репозиториев - то какое кому-то до них дело? Алсо, они оплачивают мне хостинг на гитхабе.
почему многие до сих пор на svn пихают все, у гита вроде плюсов больше ?
> почему многие до сих пор на svn пихают все, у гита вроде плюсов больше ?А нафига нужны какие угодно плюсы гита, есть возможностей предоставляемых svn а то и прости господи cvs может быть вполне достаточно? Работает - нетрожь.
> Работает - нетрожь.Я бы вас выгнал за это с вашего 2-го курса прямиком в армию. Во-первых, за категоричность, из которой к студенчеству пора бы уже вырасти. Во-вторых, за школьные ошибки. В-третьих, замечательно у таких вот недоадминов всё работает, не тронутое, пока кто-то это не сломает или не потребуется обновиться, что приведёт к переустановке сервера, гы-гы, потому что обновить систему несколькилетней давности такие не могут не поломав её - банально в силу нулевой квалификации и запущенности ситуации.
А вообще, и cvs и git "работают", т.е. свои функции выполняют. Только git делает это ВСЕГДА лучше, и умеет гораздо больше, и даже вы не пользуетесь всеми его фичами - это повод не оставаться на cvs, а поднять ж&пу, прочитать доку по git и понять, что такое современный контроль версий. Вместо cvs в вышесказанном можно использовать и svn - смысл не меняется.
Он не студент, но они не работают (про svn ещё можно препираться, про cvs уже поздно).> ВСЕГДА
Что Вы там про категоричность говорили? ;-)
У гита (при том, что я всегда предпочитаю его svn'у) есть перловый оттенок: большое количество вариантов действия/реализации на личный вкус и выбор. Это фича, но вовсе не бесплатная: приходится платить проверкой вариантов, выбором, документированием, обучением и т.п. Когда же "шаг вправо/шаг влево" просто отсутствует, среднему индусу явно проще жить :)
> Он не студент, но они не работают (про svn ещё можно препираться, про cvs уже поздно).Я писал за денежку под *NIX когда больше половины посетителей опеннета ещё поступало в начальную школу а творение с определенной поры уважаемого мною г-на Торвальдса было известно лишь весьма и весьма узкому кругу энтузиастов а боги были чуть-чуть другими :) Но... черт возьми! Ты (можно?) прав - мне действительно надоело работать :) По крайней мере в общепринятом здесь понимании этого термина.
как будто седина в бороде автоматически оправдывает любой идиотизм.
> как будто седина в бороде автоматически оправдывает любой идиотизм.Ни разу :) Благо, бородатых в нашем бизе хватает.
>> как будто седина в бороде автоматически оправдывает любой идиотизм.
> Ни разу :) Благо, бородатых в нашем бизе хватает.вообще, борода — это признак профпригодности, конечно. необходимый, но не достаточный.
исключения есть, но мало.
>> Он не студент, но они не работают (про svn ещё можно препираться, про cvs уже поздно).
> Я писал за денежку под *NIX когда больше половины посетителей опеннета ещё
> поступало в начальную школуДа я-то примерно так по походке и догадался -- Ваши постинги обычно интересно читать, разве кроме чёрной меланхолии (помните, бузил насчёт того, сколько раз видел доведённых на бзде именно до такого?).
> Ты (можно?)
Разумеется.
> прав - мне действительно надоело работать :) По крайней мере в
> общепринятом здесь понимании этого термина.Эт жаль, всё-таки сделать что интересное да притом полезное бывает очень здорово. Необязательно именно написать, порой даже "просто" помочь другим определиться, понять, собраться, не наступить на уже топтаные грабли... про меня-то в общепринятом смысле тоже сложно сказать -- кем и над чем именно работаю.
PS: хотя "они" употребил в смысле "CSCM-ы". :)
>> Работает - нетрожь.
> git делает это ВСЕГДА лучше, и умеет гораздо больше, и даже
> вы не пользуетесь всеми его фичами - это повод не оставаться
> на cvs, а поднять ж&пу, прочитать доку по git и понять,
> что такое современный контроль версий. Вместо cvs в вышесказанном можно использовать
> и svn - смысл не меняется.git не умеет докачку. если вы синхронизируете проект на 2 гб, и на 1900 мб у вас оборвалось - превед, медвед, весь проект нужно закачивать заново.
git не умеет диффы для бинарных данных. помнится, каких только костылей не придумывали гитисты, лишь бы не признавать эту проблему.
И это только то, что сразу вспомнилось.
ps. Использую hg 94% времени, svn 5% времени и bzr 1% времени, зная, когда и зачем что использовать.
> git не умеет диффы для бинарных данных. помнится, каких только костылей не
> придумывали гитисты, лишь бы не признавать эту проблему.Да ну? Во только вчера на флешку делал pull и что-то у меня не увеличилось место занимаемое репом на флешке, на величину бинаря :) З.Ы. Я бэкапил базу access из 2 файлов :)
не умеет, не умеет. там при помощи изоленты и какой-то непонятной матери привинчены хаки для этого.
> git не умеет докачку.Кажется, только через http://.
> git не умеет диффы для бинарных данных. помнится, каких только костылей не
> придумывали гитисты, лишь бы не признавать эту проблему.Ммм... вот тут не помню.
>> git не умеет диффы для бинарных данных
> Ммм… вот тут не помню.умеет, но не очень хорошо, мягко говоря. штука в другом: у гита просто нет такой проблемы, потому что это система контроля версий *исходного кода*, а не бинарной фигни. если у кого-то в проекте сплошная бинарная фигня — то зачем он взял гит тогда? да, молотком очень неудобно шурупы закручивать, факт.
есть вещи не решаемые в git. плюс дополнительные возможности git в 90% не нужны.PS если нужно 2-3 поработать с одним проектом в off-line, то на SVN проект травим hg и уже hg растаскивается. Когда off-line заканчивается и все мержится, то идут коммиты в центральный SVN. дальше hg удаляется.
Собственно, и гитом тоже можно svn-репозитории вытягивать.А что это за вещи, не решаемые в git, но решаемые в svn?
> А что это за вещи, не решаемые в git, но решаемые в
> svn?Есть несколько, не сказать что не решаемых, но несколько неудобных вещей:
1) Нельзя клонировать только поддиректорию (если это не модуль конечно).
(да, можно склонировать всю репу и откастрировать нужный путь с перезаписью хистори)2) Нельзя склонировать репу с кастрированной хистори и чтобы после этого можно было нормально использовать репу. (у --depth много ограничений)
3) Переименовывание _и_ изменение файла может привести к потере истории "новым" файлом. При больших изменениях алгоритм может не связать файлы, а контроля за процессом нет.
(Да, приходится отдельно коммитить изменение и отдельно переименовывание)Это на вскидку.
Если я где-то прослоупочил и появилось нормальное решение проблемы, то прошу меня извинить.
З.Ы. Сам я использую приемущественно Git, и имхо его плюсы с лихвой перевешивают минусы.
>А что это за вещи, не решаемые в git, но решаемые в svn?Кодировки при кроссплатформенном использовании. И svn и hg и bzr успешно решают эту проблему "искаропки", но почему-то не git по сих пор.
> Кодировки при кроссплатформенном использовании. И svn и hg и bzr успешно решают
> эту проблему "искаропки", но почему-то не git по сих пор.то есть, у гита нет костылей для систем, которые во втором десятилетии 21-го века всё ещё не умеют толком юникод? да, пичалька.
>> Кодировки при кроссплатформенном использовании. И svn и hg и bzr успешно решают
>> эту проблему "искаропки", но почему-то не git по сих пор.
>то есть, у гита нет костылей для систем, которые во втором десятилетии 21-го века всё ещё не умеют толком юникод? да, пичалька.Пользователям - ага, пичалька, что git рассматривает текст как просто поток байтов и рассчитывает на то, что внешняя(!) система одинаково этот поток байтов интерпретирует (и это во втором десятилетии 21-го века, когда никто уже не полагается на свойства внешней системы ввиду многообразия вариантов!)
> Пользователям — ага, пичалька, что git рассматривает текст как просто поток байтов
> и рассчитывает на то, что внешняя(!) система одинаково этот поток байтов
> интерпретирует (и это во втором десятилетии 21-го века, когда никто уже
> не полагается на свойства внешней системы ввиду многообразия вариантов!)и то верно. а ещё эти гады не стали писать свою файловую систему, а используют ту, что ОС даёт! и ведь рассчитывают, сволочи, что внешняя(!) система с файлами нормально работает!
да и вообще — криворучки какие-то, не хотят все нужные функции ОС заново переписать и в git интегрировать.
привет тебе, господин виндолюб, из стана нормальных ОС, где одна программа делает одну задачу — ту, для которой и была написана.
Куча бреда. Единственная разница в том, что в nix системах кодировка файловой системы не регламентируется на уровне API операционной системы, в венде регламентируется.git трактует имена файлов как массив байт, поэтому на венде этот подход не срабатывает.
>[оверквотинг удален]
>> и рассчитывает на то, что внешняя(!) система одинаково этот поток байтов
>> интерпретирует (и это во втором десятилетии 21-го века, когда никто уже
>> не полагается на свойства внешней системы ввиду многообразия вариантов!)
> и то верно. а ещё эти гады не стали писать свою файловую
> систему, а используют ту, что ОС даёт! и ведь рассчитывают, сволочи,
> что внешняя(!) система с файлами нормально работает!
> да и вообще — криворучки какие-то, не хотят все нужные функции ОС
> заново переписать и в git интегрировать.
> привет тебе, господин виндолюб, из стана нормальных ОС, где одна программа делает
> одну задачу — ту, для которой и была написана.Суровое передергивание. То есть, если программа берется делать "менеджмент" файлов и истории их изменений, то корректно работать с текстом (именами, комментариями) уже не ее задача? Git справляется с этим, но не без "косяков" в случае использования на нескольких платформах одновременно (чего нет при использовании других VCS - о чем, собственно, и речь). При чем здесь функции ОС? При чем здесь unix-way, на который вы, видимо, намекаете? То, что софт, позиционирущийся как кроссплатформенный, должен как-то учитывать (и реально во многом учитывает) особенности этих самых платформ, для вас новость?
> привет тебе, господин виндолюб, из стана нормальных ОС
Ну вам-то, конечно, явно виднее, чего я там "люб". Вы гораздо лучше знаете мои задачи и потребности. Если с чтением проблемы, то перечитайте еще раз (хинт: ключевое слово "кроссплатформенность").
Умеет оно юникод, только не UTF-8, а UTF-16, поэтому надо использовать специальные функции: например _wfopen() вместо fopen() и т.д.
Отсюда все проблемы с переносимостью.
И зачем вам тогда svn? :-)
> есть вещи не решаемые в git. плюс дополнительные возможности git в 90%
> не нужны.По вашей логике, так надо DOS'ом пользоваться, потому что в нём тоже есть программы. Давайте, расскажите какие вещи не решаются в git'е. А касательно дополнительных возможностей всё просто - они не нужны только до тех пор, пока они не нужны. А когда понадобятся, в git'е они будут, а с SVN вы идёте лесом. При том что никаких накладных расходов у git на эти возможности нет, даже наоборот - не могу представить случая где он не был бы быстее svn, даже не учитывая работу по сети.
> PS если нужно 2-3 поработать с одним проектом в off-line, то на
> SVN проект травим hg и уже hg растаскивается. Когда off-line заканчивается
> и все мержится, то идут коммиты в центральный SVN. дальше hg
> удаляется.Да-да-да, офигенный аргумент за SVN. Чем хорош SVN? Тем что вместо него можно юзать hg.
> PS если нужно 2–3 поработать с одним проектом в off-line, то на
> SVN проект травим hg и уже hg растаскивается. Когда off-line заканчивается
> и все мержится, то идут коммиты в центральный SVN. дальше hg
> удаляется.по-моему, это называется «лечить гланды через анус».
>> PS если нужно 2–3 поработать с одним проектом в off-line, то на
>> SVN проект травим hg и уже hg растаскивается. Когда off-line заканчивается
>> и все мержится, то идут коммиты в центральный SVN. дальше hg
>> удаляется.
> по-моему, это называется «лечить гланды через анус».Угу, если мне надо поработать дома над проектом я делаю на флешку или pull или Clone
Потом дома clone на комп и работаю. Затем достаточно сделать push на флешку или Clone и pull на работе. И никаких извращений. TortouseGit-ом все делается быстро и без анальных процедур... :)
> TortouseGit-омпроходи-проходи, не задерживайся.
а чем github лучше чем gitorious, правильно подозреваю что разницы никакой нет?
Тем, что не падает внезапно на пару дней и не случаются глюки с недоступностью репозитория
т.е. ничего смертельного, спасибо
> а чем github лучше чем gitorious, правильно подозреваю что разницы никакой нет?не знаю, как гитхаб, а гиториус по первому же свистку соньки грохнул репу с ps3tools. даже не разбираясь, что это, чем им может угрожать сонька и так далее. просто по щелчку сонькиных пальцев. тоже мне, «хостинг проектов». завтра ещё кто-то пальцами щёлкнет, и они ещё что-нибудь подобное сделают, испачкав от страха портки.
справедливости ради: гиториус самый вменяемый гит-хостинг под мои нужды. был до происшествия с сонькой, после которого я оттуда ушёл и возвращаться не планирую. оно, впрочем, и хорошо: давно собирался VDS обновлять, теперь туда же себе indefero поставил. как бэкапы — работает, кому надо — тот знает.
Гитхаб сделал это на неделю раньше, просто не написал в боге об этом. Так что Гиториус хоть честнее.
Вот, кстати:
https://github.com/github/dmca
http://help.github.com/dmca/
> Гитхаб сделал это на неделю раньше, просто не написал в боге об
> этом. Так что Гиториус хоть честнее.ну, я особо и не сомневался. просто в силу того, что гитхабом не пользуюсь, то про него не был в курсе.
И кстати, Гиториус в Норвегии, так что на него не действуют все эти американские запреты на экспорт средств шифрования. Хотя, на него и ДМСА не действует, они просто решили перестраховаться и не лезть на Сони.
> И кстати, Гиториус в Норвегии, так что на него не действуют все
> эти американские запреты на экспорт средств шифрования. Хотя, на него и
> ДМСА не действует, они просто решили перестраховаться и не лезть на
> Сони.так вот это меня и возмутило — что сонька им побоку совершенно, но они всё равно подпрыгнули, когда сонька скомандовала всем прыгать.
больше идти некуда, правда (как-то неудобны мне остальные), но оставаться у этих петухов желания тоже нет. утешает только что, что мои проекты тыщу лет никому не нужны, так что никто ничего не потеряет от того, что я перестану их публиковать.
Чехи спешат на помощь
repo.or.cz
> Чехи спешат на помощь
> repo.or.czя слишком тупой для неё. риальне. я там так и не смог зарегистрироваться ни разу — от них письма мне не приходят в упор. так что я понимаю, что, видимо, там возможно всё сделать, раз проекты есть — но мы несовместимы.
> а чем github лучше чем gitorious, правильно подозреваю что разницы никакой нет?В гитхабе понавешено много всяких фич в веб-интерфейсе по сравнению с гиториусом.
Если от хостинга нужен только голый гит через ssh/https то разницы особой нет.
Пользуюсь сервисом иногда, очень удобно там фрагменты кода публиковать, примеры какие-то. И даже заготовки статей для блога:)
Интересно, сколько из этих проектов представляют из себя что-то более ценное, чем "Hello, World"? Особенно среди питоноподелок.
> Интересно, сколько из этих проектов представляют из себя что-то более ценное, чем
> "Hello, World"? Особенно среди питоноподелок.а это важно? O_O
Пойду-ка я у себя на компьютере создам 3кк пустых гит-репозиториев и объявлю себя "Крупнейшим Гит-хостингом в Мире".
> Пойду-ка я у себя на компьютере создам 3кк пустых гит-репозиториев и объявлю
> себя «Крупнейшим Гит-хостингом в Мире».зачем? просто сделай скрипт, который по любому запросу будет отдавать репозиторий с приветмиром. и можешь сказать, что у тебя бесконечное количество репозиторий, пусть все утрутся — фиг переплюнут.