Почему SQLite не использует Git

1. Введение

SQLite не использует систему контроля версий Git. Вместо неё SQLite использует Fossil — систему контроля версий, специально разработанную и написанную для поддержки SQLite.

Люди часто задаются вопросом, почему SQLite, как и все остальные, не использует систему контроля версий Git. Эта статья призвана ответить на этот вопрос. Кроме того, в разделе 3 приведены подсказки для пользователей Git о том, как легко получить доступ к исходному коду SQLite.

Эта статья не является сравнением Fossil и Git. Одно из сравнений этих двух систем приведено по адресу https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki. Существуют и другие сравнения, подготовленные сторонними авторами; найдите их с помощью поисковой системы.

Эта статья не призывает вас отказаться от Git в своих проектах. Вы можете использовать любую систему контроля версий. Если Git вас полностью устраивает, продолжайте им пользоваться. Но если Git работает не так, как вам нужно, или вы задаётесь вопросом, можно ли его улучшить либо существует ли что-то лучше, возможно, вам стоит ознакомиться с приведёнными ниже взглядами. Используйте полученные знания, чтобы найти или создать другую, более совершенную систему контроля версий или просто улучшить сам Git.

1.1. Правки

Эта статья неоднократно пересматривалась, чтобы сделать её понятнее, учесть замечания и сомнения, а также исправить ошибки. Полную историю изменений этого документа можно посмотреть по адресу https://sqlite.org/docsrc/finfo/pages/whynotgit.in. (Подсказка: щёлкните по любым двум узлам графа, чтобы увидеть различия. Кстати, существуют ли веб-интерфейсы Git с похожими возможностями?)

2. Несколько причин, по которым SQLite не использует Git

2.1. Git не обеспечивает хорошую ситуационную осведомлённость

Когда я хочу узнать, что происходит в SQLite, я открываю ленту событий и на одном экране вижу сводку последних изменений во всех ветках. За несколько щелчков можно перейти к любому нужному уровню подробностей. Это можно сделать даже с телефона.

GitHub и GitLab не предлагают ничего сопоставимого. Ближе всего к этому представлению граф сети, который медленно отображается (если только он уже не закэширован), содержит гораздо меньше подробностей и почти не работает на мобильных устройствах. Представление коммитов на GitHub содержит больше подробностей, быстро отображается и работает на мобильных устройствах, но показывает только одну ветку за раз, поэтому мне трудно понять, видел ли я все последние изменения. И даже если бы GitHub/GitLab предлагали более удобные интерфейсы, оба сервиса являются сторонними. Они не входят в состав Git. Поэтому их использование добавляет в проект ещё одну зависимость.

Мне говорят, что пользователи Git часто устанавливают сторонние графические программы для просмотра репозиториев, многие из которых лучше отображают последние изменения в проекте. Это замечательно, но всё это дополнительные сторонние приложения, которые нужно отдельно устанавливать и обслуживать. Многие из них предназначены только для определённых платформ. (Например, одна из лучших программ, GitUp, работает только на Mac.) Во всех случаях сначала нужно синхронизировать локальный репозиторий, а затем открыть графический интерфейс на компьютере. И даже после всего этого, чтобы увидеть то, что мне обычно нужно, всё равно приходится выполнять несколько щелчков. Проверить состояние проекта с телефона вдали от офиса не получится.

2.2. В Git сложно находить потомков (дочерние коммиты) коммита

Git позволяет заглядывать в прошлое, но не в будущее. Для исторического коммита можно посмотреть, что было до него, но узнать, что произошло после, непросто.

В отличие от этого, Fossil предлагает удобные представления, позволяющие двигаться вперёд во времени. Вот несколько примеров:

• Все коммиты SQLite, происходящие от последнего основного выпуска

• Все коммиты, происходящие от последнего основного выпуска и вошедшие в текущую вершину ветки trunk

• Все коммиты, которые одновременно являются потомками версии 3.48.0 и предками версии 3.49.0.

• Показать прямой путь от исправления ошибки, зафиксированного 2025-02-03T13:20Z, до следующего основного выпуска.

• Сокращённый вариант предыдущего представления.

Найти потомков коммита в Git возможно — просто это сложно. Например, на странице Stack Overflow приведена последовательность команд для поиска потомков коммита в Unix:

git rev-list --all --parents | grep ".\{40\}.*.*" | awk '{print $1}'

Но это не одно и то же. Команда выше выводит список потомков, не показывая структуру ветвления, которая важна для понимания произошедшего. Кроме того, эта команда работает, только если у вас есть локальный клон репозитория; найти потомков коммита с помощью веб-интерфейсов вроде GitHub или GitLab нельзя.

Речь не только о том, чтобы время от времени находить потомков коммита. Поскольку в Fossil информацию о потомках легко получить, она широко используется на веб-страницах Fossil. Например, на каждой странице с информацией о коммите Fossil (пример) отображается небольшая диаграмма «Контекст» с непосредственными предшественниками и потомками этого коммита. Это помогает пользователю лучше ориентироваться в ситуации и предоставляет полезные возможности, например позволяет перейти к следующему коммиту в последовательности. Другой пример: Fossil легко показывает контекст вокруг определённого коммита (пример), что опять же помогает лучше ориентироваться и глубже понимать, что происходит в коде. В документации Fossil есть целая страница с дополнительными примерами.

Теоретически всё вышеперечисленное возможно и в Git при наличии нужных расширений и инструментов и использовании правильных команд. Но это непросто, поэтому такое редко делают. В результате разработчики хуже понимают, что происходит в коде.

2.3. Ментальная модель Git неоправданно сложна

Сложность Git отвлекает внимание от разрабатываемого программного обеспечения. Пользователю Git приходится помнить обо всём перечисленном ниже:

1. Рабочий каталог
2. «Индекс» или область подготовки
3. Локальная вершина
4. Локальная копия удалённой вершины
5. Фактическая удалённая вершина

В Git есть команды (и/или параметры команд) для перемещения содержимого между всеми этими расположениями и его сравнения.

В отличие от этого, пользователям Fossil нужно думать только о рабочем каталоге и коммите, над которым они работают. Это на 60% меньше отвлекающих факторов. У каждого разработчика есть ограниченный запас умственных ресурсов. Для работы с Fossil требуется меньше умственных усилий, поэтому больше интеллектуальных ресурсов остаётся для разработки программного обеспечения.

Один пользователь Git и Fossil пишет на HN:

Fossil даёт мне уверенность в том, что всё ... синхронизировано с сервером одной командой.... С git у меня такой уверенности никогда нет.

2.4. Git не отслеживает исторические названия веток

Git хранит полный DAG последовательности коммитов. Но теги веток — это локальная информация, которая не синхронизируется и не сохраняется после закрытия ветки. Из-за этого просматривать историю веток утомительно.

Например, предположим, клиент спрашивает вас: «Что в итоге стало с веткой 'prefer-coroutine-sort-subquery' двухлетней давности?» Вы можете попытаться ответить на этот вопрос, изучив историю в системе контроля версий, например так:

• GitHub: https://github.com/sqlite/sqlite/commits/prefer-coroutine-sort-subquery
• Fossil: https://sqlite.org/src/timeline?r=prefer-coroutine-sort-subquery

Представление Fossil ясно показывает, что в итоге ветка была объединена с trunk. Оно показывает, где ветка началась, а также два случая, когда изменения из trunk были объединены с этой веткой. GitHub ничего этого не показывает. Более того, представление GitHub практически бесполезно для выяснения того, что произошло.

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

2.5. Git требует больше административной поддержки

Git — сложное программное обеспечение. Чтобы установить Git на рабочую станцию разработчика или обновить его до новой версии, нужен установщик. Развернуть сервер Git непросто, поэтому большинство разработчиков используют сторонний сервис, например GitHub или GitLab, добавляя тем самым дополнительные зависимости.

В отличие от этого, Fossil — это один автономный исполняемый файл, для установки которого достаточно поместить его в $PATH. Этот единственный файл содержит все возможности основного Git, а также GitHub и/или GitLab. Он управляет сервером сообщества с вики, системой отслеживания ошибок, чатом и форумами, предоставляет пользователям пакеты для скачивания, управляет входом в систему и многое другое — без установки дополнительного программного обеспечения. Развернуть сервер сообщества на Fossil можно за несколько минут. Кроме того, Fossil эффективен. Сервер Fossil будет без проблем работать на VPS за 5 долларов в месяц или на Raspberry Pi, тогда как GitLab и подобным системам требуется более мощное оборудование.

Чем меньше административной работы, тем больше времени программисты тратят на разработку программного обеспечения (в данном случае SQLite) и тем меньше — на возню с системой контроля версий.

2.6. Git обеспечивает неудобство работы

Следующий комикс https://xkcd.com/1597/ преувеличивает ситуацию, но попадает в точку:

Будем откровенны. Мало кто станет отрицать, что Git неудобен в использовании. Многие особенности внутренней реализации заметны в пользовательском интерфейсе. Интерфейс настолько плох, что даже существует пародийный сайт, генерирующий фальшивые справочные страницы Git.

Разрабатывать программное обеспечение сложно. Это требует большой сосредоточенности. Хорошая система контроля версий должна помогать разработчику, а не раздражать его. За последнее десятилетие Git стал в этом отношении лучше, но ему ещё далеко до идеала.

3. Руководство для пользователей Git по доступу к исходному коду SQLite

Даже если вы убеждённый пользователь Git, вы всё равно можете без труда получить доступ к SQLite. В этом разделе приведены несколько подсказок о том, как это сделать.

3.1. Официальное зеркало на GitHub

С 2019-03-20 на GitHub доступно официальное зеркало Git исходного кода SQLite.

Зеркало представляет собой инкрементальный экспорт канонического репозитория Fossil SQLite. Задание cron обновляет репозиторий на GitHub раз в час. Это одностороннее зеркало кода, доступное только для чтения. Запросы на включение изменений и другие изменения через GitHub не принимаются. Репозиторий GitHub лишь копирует содержимое репозитория Fossil. Все изменения вносятся через Fossil.

Хеши, идентифицирующие коммиты и файлы в зеркале Git, отличаются от хешей в Fossil. Причин тому много, и главная из них состоит в том, что Fossil использует хеш SHA3-256, а Git — SHA1. При экспорте исходный хеш Fossil для каждого коммита добавляется в конец комментария к коммиту. Чтобы избежать путаницы, при упоминании коммитов SQLite всегда используйте исходный хеш Fossil, а не хеш Git.

3.2. Доступ через веб

В репозитории SQLite на Fossil есть ссылки для скачивания Tarball, ZIP-архива или архива SQLite для любой исторической версии SQLite. URL-адреса этих файлов просты и легко используются в автоматизированных инструментах. Формат:

https://sqlite.org/src/tarball/ВЕРСИЯ/sqlite.tar.gz

Просто замените ВЕРСИЯ описанием нужной версии. ВЕРСИЯ может быть префиксом криптографического хеша конкретного коммита, названием ветки (в этом случае будет получена её последняя версия) или тегом конкретного коммита, например «version-3.23.1»:

https://sqlite.org/src/tarball/version-3.23.1/sqlite.tar.gz

Чтобы получить последний выпуск, укажите в качестве ВЕРСИИ «release»:

https://sqlite.org/src/tarball/release/sqlite.tar.gz

Чтобы получить последний коммит из trunk, укажите в качестве ВЕРСИИ «trunk»:

https://sqlite.org/src/tarball/trunk/sqlite.tar.gz

И так далее. Для ZIP-архивов и архивов SQLite замените элемент «/tarball/» на «/zip/» или «/sqlar/», а при необходимости измените имя загружаемого файла, добавив суффикс «.zip» или «.sqlar».

3.3. Доступ через Fossil

Fossil легко установить и использовать. Ниже описаны действия для Unix. (В Windows порядок аналогичен.)

1. Скачайте автономный исполняемый файл Fossil по адресу https://fossil-scm.org/fossil/uv/download.html и поместите его в каталог, указанный в $PATH.
2. mkdir ~/fossils
3. fossil clone https://sqlite.org/src ~/fossils/sqlite.fossil
4. mkdir ~/sqlite; cd ~/sqlite
5. fossil open ~/fossils/sqlite.fossil

Теперь можно выполнить команду «./configure; make» (или в Windows с MSVC — «nmake /f Makefile.msc»).

Чтобы переключить рабочую копию на другую версию Fossil, используйте команду «update»:

fossil update ВЕРСИЯ

Укажите «trunk» в качестве ВЕРСИИ, чтобы получить последнюю версию SQLite из ветки trunk. Также можно использовать префикс криптографического хеша, название ветки или тег. Другие варианты значений ВЕРСИИ см. по адресу https://fossil-scm.org/fossil/doc/trunk/www/checkin_names.wiki.

Выполните команду «fossil ui» из каталога ~/sqlite, чтобы открыть локальную копию веб-сайта.

Дополнительную документацию по Fossil можно найти по адресу https://fossil-scm.org/fossil/doc/trunk/www/permutedindex.html

Не бойтесь изучать систему и экспериментировать. Без входа в систему вы не сможете отправить внесённые изменения, поэтому навредить проекту не получится.

3.4. Проверка целостности исходного кода

Если вам нужно убедиться, что исходный код SQLite подлинный и никак не изменялся (например, злоумышленником), это можно сделать с помощью нескольких простых инструментов командной строки. В корне дерева исходного кода SQLite находится файл с именем «manifest». В файле манифеста перечислены имена всех остальных файлов в дереве исходного кода и хеш SHA1 или SHA3-256 для каждого из них. (Для старых файлов используется SHA1, для новых — SHA3-256.) Можно написать скрипт, который извлечёт эти хеши и проверит их по файлам исходного кода. Хеш коммита — это просто хеш SHA3-256 самого файла «manifest», возможно, без последней строки, если она начинается с «# Remove this line...»

4. См. также

Другие страницы о Fossil и Git:

• Fossil и Git

• Что другие говорят о Fossil и Git

Последнее обновление этой страницы: 2025-11-13 07:12:58Z