RFC: track modules as git submodules

[tionis]

This is a request for comments from all potential users regarding the following question: Should glyph modules be tracked as submodules?

---

Pros

• Allows identifying every file in your archive by a hash/path combination
• Clarifies which version of which file was meant in links etc.
• Git native → less vendor lock-in
• When commits in the top repo are signed, they convey a chain of trust down to the deepest nested repo.
• Allows seeing all changes just by using git log -p --submodule → easier to look at changes in retrospective

Cons

• A very large count of 'updated submodule' commits that don't convey useful information

• Higher probability of git submodule merge conflicts

  Another idea would be to use the glyph config to track which glyph modules that exist in the archive and use the glyph cache to save which of these modules are initialized. This would also allow updating the modules more automatically.

[tionis]

@masukomi I'd especially like input from you, as you showed interest in the general idea before.

[tionis]

After some consideration I decided to keep glyph modules as git submodules and add a new type of glyph module called “user scripts” which are tracked directly in the main repo. Together with a custom .gitignore users can use these scripts to implement all the additional content management they need.

[masukomi]

well. i 100% missed this, and it's obviously too late, BUT... as much as i dislike the implementation of git submodules I think this is the right call.

[tionis]

After testing the git submodule approach, I decided to take a new approach I'm creatively calling "Glyph 2.0" (it's more like a 0.2.0, long live 0ver).
Glyph modules will be tracked as independent git repos wholly managed by their module script, glyph only sits in the middle and manages their location, CLI interaction, and sync. The goal for glyph is more of a very simple platform that exposes a few useful functions like a global file based config to other modules.
For devices like android phones, an approach using git work trees will also be supported. This change will also improve the integration with external tools like Git Journal, Obsidian and Co significantly.
I will also carry over this change in philosophy into the example modules.
Important to note here that the biggest disadvantages of this change are performance and maybe security.

• Performance is lost mostly during sync as the sync complexity changes from $O(1)$ git fetch operations to $O(n)$ fetches
• Security in the form of only having the trust the (maybe signed) commits in the main repo is also lost