Как организовано одно дерево с помощью git?
Недавно я натолкнулся на статью Грега Кроа-Хартмана о том, почему ядро Linux не имеет стабильного API и как хранилище ядра организовано как одно дерево. Когда я обсуждал статью с другом, стало ясно, что у нас было другое понимание того, что термин tree применительно к:
treeотносится к различным подпапкам проекта.- Это относится к разным ветвям ветки git master.
В первом случае участники не будут проверять весь проект, например, ядро Linux, а только подпапку. Затем они могут быть объединены с, например, git-subtree,
Во втором случае участники должны были бы проверить весь проект и в основном создать форк монорепо.
Так что же tree в monotree ссылаются и как проект может быть организован как monotree с git?
1 ответ
Давайте сделаем несколько заметок здесь:
- Фраза monotree, или даже частичное слово mono, никогда не появляется в указанной статье.
- В статье есть семь вхождений дерева слов.
- В шести из этих семи случаев вся фраза здесь является основным деревом ядра. Одна ссылка, которая не использует эту полную фразу, просто говорит о дереве, но явно имеет то же намерение, что и остальные шесть.
- Вы отметили это с помощью git linux monorepo (на случай, если теги изменятся).
Ваш вопрос сводится к следующему: что автор подразумевает под фразой "главное дерево ядра"? или что вообще имеют в виду люди, когда ссылаются на дерево? Это правильные вопросы, но они не особенно актуальны для Git.
Древо в информатике имеет тенденцию ссылаться на структуру данных, которая также довольно слабо определена; смотрите запись в википедии. У нас есть некоторый набор узлов и ребер - математически граф G, определенный его множеством вершин V и ребер E, где каждая вершина соединяется ребрами с другими вершинами, и существуют ограничения на графе, так что он минимально связан, или эквивалентно, максимально ациклический. (См. https://en.wikiversity.org/wiki/Introduction_to_graph_theory/Proof_of_Theorem_4 и ответы на вопросы В чем разница между структурой данных Tree и Graph?)
Объект дерева в Git, в частности, ссылается на сохраненный объект Git "дерева" Git-типа (один из четырех типов объектов Git, которые хранятся в базе данных репозитория; остальные три - это commit, blob и аннотированный тег). Такой объект хранит тройки
1 Существует ограничение длины из-за записи в кеш ce_namelen поле, которое имеет 32-битный целочисленный тип. Таким образом, длина имени компонента не может превышать 4 ГБ. Практически говоря, ни один из них, вероятно, не должен превышать 255 байт, но объекты дерева в Git, насколько я знаю, не устанавливают никаких конкретных ограничений.
Дерево файловой системы в Linux на самом деле является просто строкой, идентифицирующей сущность в файловой системе, хотя присвоение имени чему-либо, кроме каталога, приводит к вырожденному дереву с одним узлом в нем. Однако, называя каталог, вы можете подразумевать, что любой, кто интерпретирует эту строку, должен прочитать содержимое каталога, то есть имена, которые (будучи соединенными со строкой, идентифицирующей сам каталог), называют другое дерево файловой системы Linux, возможно, вырожденное с один файл или узел устройства или что-то еще. Этот вид рекурсивного перечисления приводит к построению минимально связного графа, так же как и с объектом дерева Git. (Возможно, неудивительно, что объекты каталогов Linux по существу имеют те же ограничения на имена, что и объекты дерева Git, хотя обычно они имеют гораздо меньшую максимальную длину имени компонента, обычно 255 байт или меньше.)
Наконец, то, как фраза "основное дерево ядра" используется в статье, относится к репозиторию ядра Linux - Git-репозиторию Линуса Торвальда для ядра Linux - и всей экосистеме вокруг него. Существует много места для споров о деталях. Здесь я просто включу ссылку на эту конкретную статью в InfoWorld, которая выглядит как разумное резюме положения дел на момент ее написания (август 2016 года).