Comments 55
Ну, это просто как клей исходного кода вокруг блоба, но поскольку он может содержать никаких частей ядра по юридическим причинам, это прекрасный пример.
Вот тут я получил вывих мозга.
Честно говоря, немного не понял как осуществляется процесс отправки патча от разработчика к мейнтейнеру.
Может кто-нибудь сказать: почему нельзя вместо отдельных репозитариев — по сути форков — в которых ведётся работа над подсистемами, использовать ветки? Сугубо с точки зрения разделения кода. Если я правильно понял (не факт, что правильно понял — я всё ещё объят сном, сейчас мне кто-нибудь объяснит, я хлопну себя по лбу и скажу: а-а, да… пардон, я сонный), то вместо разделения проекта на модули ядро просто назначает: вот в этой копии репозитария мы работаем над сетью, а в этой над файловой системой. Потом контрибьюторы шлют изменения, майтайнеры анализируют их и возможно координируют дела со смежными форками (если изменения затрагивают несколько подсистем или ведётся конфликтующий набор изменений), потом всё идёт ещё выше большими пулл-реквестами, и в конце-концов приземляется в репозитарии Линуса. Так репозиторий один, весь код виден всем сразу, но работа организована иерархически. Поэтому мне просто интересно, не могут ли — чисто технически — долгоживущие ветки (на стороне основного репозитария) заменить отдельные репозитарии. Договориться об именовании веток (скажем, в net майнтайнер будет собирать работу для сети, а дальше в net/* уже ведутся изменения, из которых посылать патчи), должно такое работать или нет? Просто я смотрю на копии репозитариев у майнтайнеров подсистем (и опять же, скорее всего чего-то важного не вижу), и они мне кажутся такими glorified branches.
По крайней мере с правами доступа проблема. Насколько я понимаю для связки типа git+ssh нельзя назначить доступ людям на основе веток. В github вроде нет таких проблем. Но с ним другая проблема, если всю работу сосредоточить в одном репозитории с ветками для мантейнеров есть большая вероятность утонуть под количеством issue и pull request, даже при наличии меток и прочего.
Вроде бы можно… я не уверен, но, помнится, ещё gitolite в своё время позволял назначать очень мелкозернистые права, ограничивать пространства имён веток, где и кому можно создавать ветки (например, студентам разрешить создавать ветки под lab1/*), квоты — как будто всё для этого имелось. Поправьте, если кто лучше знает.
Ну и с issue — это уже другая проблема, я именно поэтому уточнил "… сугубо с точки зрения разделения кода", бактрекер — это уже не контроль версий. Меня интересовало, это мне чудится, или действительно такие копии репозитариев — это на самом деле такие вручную сделанные ветки. Кстати, а pull request при чём? Я имею в виду не гитхабовский pull request, а просто — почему можно формировать pull request между копиями репозитариев, но нельзя тем же способом между ветками?
Меня интересовало, это мне чудится, или действительно такие копии репозитариев — это на самом деле такие вручную сделанные ветки.Не вручную всё-таки, а с помощью специально для этого написанной программы. Git называется.
Просто Линус вдоволь насмотрелся на тему срача вокруг «committer access»а и «branch creation criteria» в разных *BSD и GCC и был принципиально против системы в которой понятие «committer access» вообще существует.
Так репозиторий один, весь код виден всем сразу, но работа организована иерархически.Собственно git изначально был написан так, чтобы удовлетворять одному простому требованию: код, написанный Intel для поддержки ещё не выпущенных процессоров Intel (на самом деле тогда Transmeta — но неважно), должен физически находиться только на серверах Intel (с контролируемым доступом, понятно).
В этом — смысл D в DVCS. Линус категорически отказывался пользоваться VCS, которые не удовлетворяли этому условию, а когда доступа к единственной системе контроля версий, удовлетворяющей этому условию (и при этом «промышеленной», не умирающей на проектах масштаба ядра Linux), его лишили — написал свою.
Просто я смотрю на копии репозитариев у майнтайнеров подсистем (и опять же, скорее всего чего-то важного не вижу), и они мне кажутся такими glorified branches.Они и есть «glorified branches» — но с двумя важными отличиями:
- Кто угодно может их создавать не спрашивая ничьего разрешения
- Об их существовании нельзя узнать если только сам автор этого не захочет
Оба момента для Линуса были принципиально важны.
Нет-нет, я понимаю саму оригинальную задумку DVCS — чтобы у каждого был полноправный репозитарий, а коммиты могли курсировать между репозитариями. (Про нюанс с проприетарным кодом Intel — вот этого не знал.) Меня интересовал сам технический вопрос, в более узком смысле — автор упомянул, что от гитхаба им нужно только более гибкое взаимодействие между форками (чтобы они трактовались как части одного проекта), вот и подумалось, что по сути-то они трактуют репозитарии как ветки. Понятно, что всё ещё потребуется возможность анонимного создания веток контрибьюторами.
На GitHub [пулл-реквесты] это единственный способ разработчикам внести предложенные патчи в общий код.Довольно странное утверждение. Можно открыть ишью и приложить патч (я обычно так и делаю), можно дать ссылку на сторонний багтрекер или репозиторий. Часто, действительно, просят сделать pull request, но лично мне это неудобно. Иногда я иду навстречу, иногда вежливо отказываюсь, объясняя, что постоянно работать над этим кодом не собираюсь, и смысла клонировать проект только для того, чтобы сделать один-два пулл-реквеста, не вижу.
Я думаю, тут смысл в том, что единственный более удобный, чем то, что уже используется сейчас. Более того, мне кажется, что формат рассылки более удобный, чем открывать issue, но это уже детали.
Закоммитить локально, сформировать письмо с патчем (git format-patch), потом отправить по почте кому-нибудь (git sendmail). Например, другим разработчикам проекта. А чтобы применить изменения, сделанные другими пользователями, нужно получить письмо с патчем и выполнить git am.
Т.е. грубо говоря, git push в удалённый репозиторий заменяется на git sendmail, а git pull на git am. При этом вариант с почтой получается p2p, т.е. изменения пользователям приходят напрямую от других пользователей.
Там в целом написано. Сам по себе Linus никому не указ, у каждой компании своя ветка, так что если репозиторий чисто Linus'а больше не будет работать, существенно ничего не поменяется. Ведь по сути, ни в одном дистрибутиве Linux нет ванильного ядра.
Если Линус лично принимает все изменения в мастер репозиторий и выкатывает релиз, то в случае, если он не будет в состоянии этого делать, кто будет ответственен за дальнейшие релизы?Я думаю вначале будет много неразберихи, но через год-два всё устаканится.
А главное, будут ли компании-производители доверять этому человеку или каждый сделает свой форк и начнется хаос?А этих «форков» и сейчас… как грязи. Большинство железячников, в частности, ядро от Линуса не волнует от слова «никак» — они пользуют ядро от Android'а. А многие — и куда более древние ядра от разных компаний.
В том-то и фишка, что ядро Линукса — это реально распределённый проект и очень многие фичи годами живут вне основной ветки. Чисто так для примера: OverlayFS в ядре Линуса появилась-таки в 2014м году. Притом что первая версия этой идеи (под названияем IFS — Inherited File System) появилась в Slackware, на минуточку, в 1993м (sic!) году.
если он не будет в состоянии этого делать, кто будет ответственен за дальнейшие релизы?
ИМХО кто-нибудь из основных разработчиков. Грег Кроа-Хартманн, например.
Мне кажется автор статьи, за кучей текста, упустил один простой момент. Распределённый репозиторий он на то и распределённый, что не хостится в одном месте. Никто не запрещает хостить на гитхабе свой форк ядра и слать из него патчи в апстрим. Думаю многие так и делают. Никто не запрещает делать то же самое на любом другом публичном гит-хостинге, либо где-то на своём сервере.
Каждый выбирает то что лично ему удобнее (включая Линуса, выпускающего официальные релизы со своей ветки). Очевидно, свой сервер всегда будет более гибким, чем чей-то (например гитхабовский), поэтому всегда будут те, кто эту гибкость желает использовать.
А те, кто ВСЮ работу с кодом ведут только через один хостинг — по сути не используют распределённость, ради которой гит создавался, и с тем же успехом могли бы пользоваться свн (наверно даже удобнее, если распределённость не нужна), но выбрали гит по причине модности.
Попробуйте в svn использовать какой-то git-flow и вы почувствуете боль. Реальная полезность git'а, за которую его любят разработчики, в духе "одна фича — одна ветка" и прочие штуки не зависят от того, где именно его хостить.
Ну очевидно что конкретный инструмент "git-flow" был сделан для git. Но не вижу проблем реализовать ту же логику и в svn, если всё в одном репозитории на одном сервере. Есть ли для этого готовые инструменты или нет — не в курсе.
У svn, если я не ошибаюсь, под новую ветку создается полная копия, а не хранятся коммиты. В итоге оно все выглядит очень тяжело.
Ну и да, как я тут почитал, в svn я не могу на локальной машине все делать и делать коммиты, а потом такой svn push. Там коммитить нужно сразу в мастер репозиторий. Так что разработчики автоматически используют преимущество git.
"Полная копия" любого дерева в свн делается за мгновение, детали не изучал но очевидно данные при этом не копируются а просто делается пометка что копия = оригиналу в этой ревизии.
git push = svn commit (перенос локальных правок на сервер)
git commit = svn просто локальные правки, да их нельзя сортировать и подтверждать инкрементально перед отправкой на сервер, как в гите, забыл про это отличие, но по-моему оно и не особо нужно и может даже мешать лишними действиями при централизованном репозитории (хотя кому как)
Но вот переключение, бранчей, например, делается дольше: https://habrahabr.ru/post/320704/
Ну и да, возможность коммитить локально — очень полезная штука, которая позволяет забить, скажем, на временную недоступность централизованной штуки (например, gitlab.com в последнее время иногда падает).
В svn merge всегда будет болью, а если мержиться практически невозможно — никакой инструмент не поможет.
Потому что этот новый форк будет никому не нужен?)
А зачем вообще разработчикам ядра фичи гитхаба? Git сделан децентрализованным и распределенным прежде всего потому, что сама модель разработки децентрализована. E-mail — тоже в достаточной мере децентрализованная штука. А гитхаб (в смысле, не репозиторий на нем, а issues и pull requests) станет single point of failure.
Это вы о чем вообще? Если про гитхабовский git-клиент — он делался для домохозяек, никто не мешает использовать обычный консольный git.
Это проблемы Git
Да нет, это проблемы ленивых людей не любящих читать мануалы и профильные книги и отчего-то уверенных, что кто-то за них обязан придумать кнопку на каждую функцию. Гит это хороший, увесистый молоток. К нему можно даже приложить комикс из трех картинок по использованию(гуй). Только вот, если руки из задницы и сам ты ленивый забивать им гвозди лучше не получится.
В JetBrains-овских IDE в целом сделано неплохо, но некоторые вещи удобнее делать с консоли. Я совмещаю.
Ну и add -p там вообще нет, тикет уже 7 лет висит. Хотя вроде начались подвижки.
Это не пользователи github, а большинство пользователей git. Для мелких проектов с полутора разработчиками большего и не требуется. А если начнут работать в нормальной команде — научатся, никуда не денутся (достаточно будет один раз получить по шапке).
Дай бог в GitLab запилят, они иногда быстрее фичи выпускают
Почему GitHub не может хостить ядро Linux