Math talk: Теорема о системе контроля версий git?

Я хотел бы выступить с математикой о системе контроля версий git . В настоящее время он широко используется в математике, а также в индустрии компьютерных наук. Например, сообщество HoTT (Homotopy Type Theory) использует его, и это система перехода к совместному редактированию текстовых файлов, будь то исходный код или разметка латекса.

Я знаю, что git использует понятие ориентированного ациклического графа, что является началом. Тем не менее, хороший математический разговор упоминает доказательства и теоремы.

Какую теорему я могу доказать о git, которая на самом деле имеет отношение к его использованию?

Git-репозиторий можно рассматривать как частично упорядоченный набор ревизий (где одна ревизия является более ранней, чем другая в порядке, если она является прямым или косвенным преемником более ранней). Частичные заказы, которые вы получаете из репозиториев git, имеют тенденцию иметь низкую ширину (размер наибольшего набора взаимно независимых ревизий), потому что ширина напрямую связана с количеством активных разработчиков и количеством различных вилок, которые может работать любой отдельный разработчик. на.

Исходя из этого, я бы предложил теорему Дилворта , которая гласит, что ширина любого частичного порядка равна минимальному количеству цепочек (полностью упорядоченных подмножеств), необходимых для охвата всех версий. И чтобы сделать это тематическим для этой платы, вы могли бы также упомянуть алгоритмы на основе сопоставления графов для вычисления ширины и нахождения покрытия по минимальному количеству цепей за полиномиальное время.

Одним из способов, которым это может быть актуально для фактического использования в Git, является система для визуализации истории версий системы: большинство систем визуализации Git, которые я видел, рисуют время по вертикальной оси, а независимые версии репозитория по горизонтали, поэтому даст вам способ организовать визуализацию в небольшое количество независимых вертикальных дорожек.

В качестве альтернативы, если вы хотите что-то более амбициозное и продвинутое, попробуйте структуру данных дерева обвинений Demaine et al., Которая напрямую мотивируется разрешением конфликтов в git-подобных системах контроля версий.

Интересно, что зарождается математизация систем контроля версий, хотя на данный момент это только частично применимо к Git. Она называется теорией патчей [1, 2, 3, 4, 5] и возникла в контексте системы контроля версий DARCS. Это можно рассматривать как абстрактную теорию ветвления и слияния . Недавно теория патчей получила HoTT [6] и категорическое [7] лечение.

Теория патчей находится в стадии разработки и не охватывает все аспекты контроля версий, но содержит множество теорем, на которые вы могли бы взглянуть. Это яркий пример теории, которая применима к «реальному миру» - неудивительно, поскольку теория патчей - это абстракция / упрощение чего-то очень конкретного. В то же время он соединяется с передовой математикой, такой как HoTT.

1. Дж. Дагит, Типо-корректные изменения - безопасный подход к внедрению контроля версий .
2. Г. Ситтампалам, Некоторые свойства теории патчей Дарка .
3. I. Lynagh, Теория пути лагеря.
4. D. Roundy, Реализация формализма патчей darcs ... и проверка его.
5. J. Jacobson, Формализация теории Даркса Патча с использованием обратных полугрупп .
6. C. Ангиули, Э. Морхаус, Д.Р. Ликата, Р. Харпер, Теория гомотопических патчей .
7. С. Мимрам, С. Ди Джусто, Категориальная теория патчей .

Другой альтернативой является рассмотрение постоянных (или чисто функциональных) структур данных. Внутренняя структура данных Git может рассматриваться как устойчивое дерево :

постоянная структура данных - это структура данных, которая всегда сохраняет свою предыдущую версию при ее изменении. Такие структуры данных являются фактически неизменяемыми, поскольку их операции не (заметно) обновляют структуру на месте, а вместо этого всегда дают новую обновленную структуру.

Структура данных является частично персистентной, если все версии доступны, но только самая последняя версия может быть изменена. Структура данных полностью постоянна, если к каждой версии можно получить доступ и изменить. Если есть также операция объединения или слияния, которая может создать новую версию из двух предыдущих версий, структура данных называется конфлуентно-постоянной.

Этот вопрос тоже актуален.

Да, вы можете математически определить, как работает Git. Вы можете определить примитивные структуры Git и операции Git на них, а затем получить теоремы, которые доказывают, что использование этих операций определенным образом достигает конкретных целей более высокого уровня, или пытаться охарактеризовать или количественно оценить ситуации, в которых это не так. (Например, зависимость Git от хэшей оставляет небольшое поле для ошибки.)

Другая идея состоит в том, чтобы сделать то же самое для Subversion, а затем создать теоремы, которые сравнивают их. Например, часто утверждается, что Git лучше справляется со слияниями; Вы можете иметь теоремы, которые доказывают это, качественно или количественно.

Полезность будет критически зависеть от правильных абстракций. Математически описывать работу исходного кода Git во всех деталях бессмысленно: сам исходный код делает это намного эффективнее и лаконичнее.