Идея для организации структуры в папке db #20

Сделав форк оригинального репозитория, я немного поразмыслил над тем, насколько "всё это" (содержимое папки /db) будет удобно для конечного пользователя.

Необходимо помнить, что мы работаем не с репозиторием де-факто как таковым, а с vault-ом Обсидиана (сторонней программы). Vault - это отдельная сущность в Обсидиане; по сути это папка с файлами/структурой/связями и т.д. Представьте, что мы хотим интегрировать уже имеющиеся у разных пользователей vault'ы в нашу базу знаний, причём таким образом, чтобы можно было выбрать, что именно "подключить" к основной базе.

В чём суть проблемы

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

Необходимо дать пользователю максимальный уровень свободы: чтобы не он делал форк, а чтобы мы могли подключать базы знаний сторонних пользователей как модули расширения нашей основной базы. Почему? Потому что очень немногие захотят работать с уже имеющейся структурой файлов основного репозитория, а многие попросту запутаются.

Иными словами, организацию вида структуры нужно делегировать конечному пользователю, а не задавать нашим основным репозиторием. Например, то, что собирал в папке db/ пользователь redboo, должно быть мягко разграничено с тем, что хочет добавить пользователь scsmash3r. Иначе будут постоянные конфликты мерджей, синхронизации с актуальной версией между форками и куча другого головняка. При этом нужно, чтобы связи всё-таки оставались, но были неявными.

Возможное решение

Вместо фактического создания форков и строгой проверки пушей (вручную) у git'а есть вот такая штука, которая называется подмодули.

Подмодули решают такие проблемы:

• основной репозиторий не нужно форкать, а значит не нужно "плодить сущности" и дублировать кучу файлов из assets/. Необходимо беречь байты =)
• основной репозиторий задаёт только базовую структуру и может служить примером для организации других vaultов (которые представлены именно как подмодули).
• другие vaultы пользователей - это независимые digital gardens, которые любой другой юзер (или владельцы основного репозитория) могут подключать с помощью файла .gitmodules.

В сухом остатке: вместо форков и полного строгого дублирования всей структуры мы можем обходиться "мягким" подключением подмодулей (других репозиториев), которые будут представлены как vaultы пользователей в нашей основной папке db/. В итоге это будет выглядеть как-то так:

Основной репозиторий без подмодулей:

db/00 Книги.md
db/00 Наука.md
[...]
Zettelkasten Цеттелькастен.md

Затем, если мы решили добавить подмодуль (репозиторий) другого пользователя scsmash3r, который также ведёт какую-то базу материалов (это делается с помощью .gitmodules), то структура будет следующей:

db/scsmash3r/00 Общая семантика.md
db/scsmash3r/someotherstuff.md
db/00 Книги.md
db/00 Наука.md
[...]
Zettelkasten Цеттелькастен.md

Таким образом, можно будет не только работать с форком и менять основную базу (мало кто будет заниматься изменением существующей структуры, т.к. необходимо ждать пул и решать возможные конфликты), но и подключать базы данных (vaults) других пользователей, которые могут быть даже не знакомы с основным репозиторием (что будет проще для многих пользователей и также позволит формировать свои базы данных на основании того, интересует ли их digital garden другого пользователя или нет).

Плюсы:

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

Вопросы:

1. Есть ли в варинате с субмодулями подводные камни, которые могут привести к проблемам?
2. Есть ли смысл подумать о механизме, которые после объедиения нескольких баз выполнит проверку на дублирование информации?
3. Нужны ли дополнительные рекомендации к структуре базы/информации, которые позволили бы сделать слияние баз качественным?

Почему все файлы в одной папке?

Первоначально было задумано использовать систему ведения заметок Zettelkasten, подробнее в статье.

Как добавить свою базу?

Для начала стоит определиться, хотите ли вы делиться публично своими заметками? Если ответ утвердительный, то рассмотрите возможность пересмотра структуры своей бызы в сторону Zettelkasten.
Если пользователь хочет вести приватные заметки (т.е.: "моя, структурированная по-моему база, никому не покажу"), то достаточно создать свою папку и добавить её в исключение файла .gitignore или воспользоваться уже существующими daily (для ежедневных быстрых заметок) и ideas (заметки на тему ИДЕЯ!).