И что вам, жалко что кроме таких же проектов у которых «приятно читать описание» там выкладывается всё подряд? Как минимум, люди используют эти репозитории чтобы отовсюду иметь доступ к своему коду, студенты наверняка смотрят код друг друга, ну и не так уж редко из личных репозиториев вырастают хорошие проекты. Также, выкладывание кода в паблик приучает всегда писать код за который не стыдно. Отказаться от этого всего, чтобы вам было красиво? Ну нет. Всё творчество в паблик — только так и должно быть. А псевдоэлитизм никогда положительных чувств не вызывал.
Пожалуй. Есть антипаттерны которые сразу уменьшают желание вкладываться в проект (например, отсутствие или самопальная системы сборки, dll'ки и прочие бинарники в репозитории, комментарии/README не на английском), возможно при таком анализе всплывут новые.
Это отчасти верно, ибо важен не Github как таковой, а hub в общем — место в котором пересекаются все проекты и разработчики. Сейчас это github, случится что-то с ним, таковым автоматически станет следующий по популярности хостинг, например BitBucket, причём благодаря git переезд будет совершенно безболезненным (поэтому аргументы против github что де это «все яйца в одной корзине» — ерунда).
Но заслуга Github не только в этом — он первый уменьшил сложность контрибутинга в чужой проект до одного клика, и по удобству до сих пор остаётся эталоном.
> больше похож на свалку кода
Любой хостинг похож на свалку кода. Иначе им вообще никто не пользуется.
> О публикации кода на Github или другом открытом хостинге часто говорят, как о такой живительной эвтаназии, после которой патчи, фиксы, сообщения о проблемах и прочие коммиты от сторонних разработчиков польются рекой.
Вероятно, вы неправильно интерпретировали тезис. GitHub — не достаточное, но необходимое для этого условие. Сейчас, когда каждый уважающий себя разработчик и проект зарегистрированы на гитхабе, с одной стороны, вносить вклад и втягиваться в разработку чужих проектов стало несравнимо легче, с другой — делать это вне GitHub люди уже не хотят, особенно когда для каждого проекта нужно пройти регистрацию, разобраться с очередным багтрекером, понять как прикрепить патч и т.д.
GitHub стирает барьеры на пути контрибуторов, но приток этих самых контрибуторов магическим образом не обеспечивает — это уже ваша забота сделать интересный проект и рассказать о нём людям, если вы хотите чтобы вам помогали. Если же создать репозиторий с каким-нибудь велосипедом и ждать у моря погоды, разумеется никто не придёт.
У меня лично опыт сугубо положительный: несмотря на то что как раз ни направленных на широкую аудиторию, ни разрекламированных проектов у меня нет, вклад со стороны приходит регулярно, и сам я никаких проблем со вкладом в чужие проекты не испытывал (кажется, у меня порядка 160 закрытых pull'ов и 5 чужих проектов в которые я могу коммитить напрямую). Без Github такое было бы просто невозможно.
Касательно же вашей статистики, кроме пробелов которые вы упомянули сами (и которые уже лишают её репрезентативности) нужно учитывать что Github помимо прочего обладает тем свойством что туда хочется выкладывать всё подряд включая наброски и эксперименты. Ничего плохого в этом нет, но значительная часть репозиториев просто не предусматривает и не ожидает стороннего вклада. Считать по ним что-то бессмысленно, а простого способа отделить их скорее всего не существует.
> предлагаю провести тест и сэмулировать ситуацию с «недописаным» файлом в дереве
Тест некорректен. При записи коммита сначала записываются блобы, потом tree, потом commit, потом обновляется ветка. Если вы тестируете падение во время записи коммита, откатывайте изменения с конца. Нетрудно видеть, что репозиторий всегда остаётся в консистентном состоянии: ветка обновится только когда коммит будет целиком записан, коммит — только когда будут записаны все его tree, tree — только после блобов, так что как и с транзакцией fossil, потеряем только текущий коммит. Однако, в отличие от fossil, уже записанные части коммита можно будет извлечь, а не потерять навсегда при rollback'е транзакции. Так что git всё-таки надёжнее.
Пишут евангелисты которых такое впечатление что у hg гораздо больше чем пользователей. А переходят те кто сравнил обе VCS в работе. Я вот тоже начинал с mercurial, но нашёл git гораздо более удобным, логичным и простым.
Хостят, разумеется. Иногда основной софтварный продукт компании открыт, часто выкладываются побочные проекты типа инструментов, плагинов, примеров и документации. Помимо этого есть приватные репозитории и целый приватный гитхаб (https://enterprise.github.com/).
Помню я этот perforce в google. Над ним были запилены по меньшей мере две обёртки чтобы можно было вытаскивать только нужные файлы, и всё равно работало оно кошмарно медленно и неудобно.
Было бы здорово как-нибудь комментировать такие снимки для неподготовленных, потому чтобы разобраться что видно нужно просмотреть гифку много раз. Есть тёмные пятна — это, полагаю, поверхность. Есть слой с шумом и пупырышками — что это? Похоже на дефекты оптики или матрицы, учитывая что он движется плоско и хаотично. И есть собственно облака, на фоне правого тёмного пятна.
Только речь-то про то как проблему решить не изменяя репозиторий. Например, у вас банально нет прав за запись, или полиси проекта такое что нужны директории с двоеточиями (например, какие-нибудь имена классов/модулей). Повторяю, svn ничем не поможет.
Это неправда, git хранит именно целиковые файлы и директории (в объектах blob и tree соответственно), а pack'и их этих объектов дополнительно сжимаются эффективной delta компрессией. Но, честно говоря, не знаю как к обсуждаемому вопросу вообще относится внутреннее представление данных в VCS.
Вы составляете мнение о git на основании одного случая, почему-то решив что именно он показательный. Для любого нехарактерного паттерна использования сложного инструмента нужно читать документацию. Для git нехарактерен sparse checkout, для svn нехарактерны, например, локальные коммиты — когда понадобится работать с репозиторием оффлайн, велкам читать про всяческие svnsync и svn switch, а потом про слияние этого дела.
> Нафига мне нужна история, если я хочу работать с файлам?
Так зачекаутите после clone только то что нужно и работайте. git clone --no-checkout && git reset && git co <нужные файлы/директории>
А почему вы проблему системы валите на git? Если бы двоеточие оказалось в каталоге который вам нужен, даже svn никак бы вам не помогла. А вообще, git умеет по меньшей мере два способа обойти эту проблему (которую не надо считать элементарной при том что полнота и целостность репозитория как-бы лежит в основе DVCS): git clone --no-checkout и sparse checkout (git help read-tree).
Хорошо если они продолжат публиковать свои разработки под Apache 2.0 или другими «нормальными» свободными лицензиями, и не вспомнят про свои закрытые RSL/LPL/LRL и GPL-несовместимые PL/RL.
Это отчасти верно, ибо важен не Github как таковой, а hub в общем — место в котором пересекаются все проекты и разработчики. Сейчас это github, случится что-то с ним, таковым автоматически станет следующий по популярности хостинг, например BitBucket, причём благодаря git переезд будет совершенно безболезненным (поэтому аргументы против github что де это «все яйца в одной корзине» — ерунда).
Но заслуга Github не только в этом — он первый уменьшил сложность контрибутинга в чужой проект до одного клика, и по удобству до сих пор остаётся эталоном.
> больше похож на свалку кода
Любой хостинг похож на свалку кода. Иначе им вообще никто не пользуется.
Вероятно, вы неправильно интерпретировали тезис. GitHub — не достаточное, но необходимое для этого условие. Сейчас, когда каждый уважающий себя разработчик и проект зарегистрированы на гитхабе, с одной стороны, вносить вклад и втягиваться в разработку чужих проектов стало несравнимо легче, с другой — делать это вне GitHub люди уже не хотят, особенно когда для каждого проекта нужно пройти регистрацию, разобраться с очередным багтрекером, понять как прикрепить патч и т.д.
GitHub стирает барьеры на пути контрибуторов, но приток этих самых контрибуторов магическим образом не обеспечивает — это уже ваша забота сделать интересный проект и рассказать о нём людям, если вы хотите чтобы вам помогали. Если же создать репозиторий с каким-нибудь велосипедом и ждать у моря погоды, разумеется никто не придёт.
У меня лично опыт сугубо положительный: несмотря на то что как раз ни направленных на широкую аудиторию, ни разрекламированных проектов у меня нет, вклад со стороны приходит регулярно, и сам я никаких проблем со вкладом в чужие проекты не испытывал (кажется, у меня порядка 160 закрытых pull'ов и 5 чужих проектов в которые я могу коммитить напрямую). Без Github такое было бы просто невозможно.
Касательно же вашей статистики, кроме пробелов которые вы упомянули сами (и которые уже лишают её репрезентативности) нужно учитывать что Github помимо прочего обладает тем свойством что туда хочется выкладывать всё подряд включая наброски и эксперименты. Ничего плохого в этом нет, но значительная часть репозиториев просто не предусматривает и не ожидает стороннего вклада. Считать по ним что-то бессмысленно, а простого способа отделить их скорее всего не существует.
Да.
> существует возможность поломать репозиторий при отключении питания
Нет. Запись нового файла + rename(2), последний атомарен.
Тест некорректен. При записи коммита сначала записываются блобы, потом tree, потом commit, потом обновляется ветка. Если вы тестируете падение во время записи коммита, откатывайте изменения с конца. Нетрудно видеть, что репозиторий всегда остаётся в консистентном состоянии: ветка обновится только когда коммит будет целиком записан, коммит — только когда будут записаны все его tree, tree — только после блобов, так что как и с транзакцией fossil, потеряем только текущий коммит. Однако, в отличие от fossil, уже записанные части коммита можно будет извлечь, а не потерять навсегда при rollback'е транзакции. Так что git всё-таки надёжнее.
В гугле? Сомневаюсь.
> У меня все летает даже домашнем старом, перегруженном сервере.
У вас репозиторий гугловских размеров?
Пишут евангелисты которых такое впечатление что у hg гораздо больше чем пользователей. А переходят те кто сравнил обе VCS в работе. Я вот тоже начинал с mercurial, но нашёл git гораздо более удобным, логичным и простым.
> svn грубо говоря, хранит папки и файлы, git хранит изменениня
Это неправда, git хранит именно целиковые файлы и директории (в объектах blob и tree соответственно), а pack'и их этих объектов дополнительно сжимаются эффективной delta компрессией. Но, честно говоря, не знаю как к обсуждаемому вопросу вообще относится внутреннее представление данных в VCS.
Вы составляете мнение о git на основании одного случая, почему-то решив что именно он показательный. Для любого нехарактерного паттерна использования сложного инструмента нужно читать документацию. Для git нехарактерен sparse checkout, для svn нехарактерны, например, локальные коммиты — когда понадобится работать с репозиторием оффлайн, велкам читать про всяческие svnsync и svn switch, а потом про слияние этого дела.
> Нафига мне нужна история, если я хочу работать с файлам?
Так зачекаутите после clone только то что нужно и работайте. git clone --no-checkout && git reset && git co <нужные файлы/директории>
> sparse checkout ругнулся
Это не команда, я написал какой help надо прочитать. Подробнее написано тут: briancoyner.github.io/blog/2013/06/05/git-sparse-checkout/. На другие репозитории это никак не влияет.