|
| 1 | +# what is zit |
| 2 | + |
| 3 | +Zit is a combination of "Zettelkasten" and "Git". Zettelkasten is a |
| 4 | +knowledge-management method that is used by academics and professionals to graph |
| 5 | +their thinking to make it more usable and navigable. |
| 6 | + |
| 7 | +Zit both Zettelkasten and Git as inspiration: |
| 8 | + |
| 9 | +- everything has an automatically-assigned identifier |
| 10 | +- flat hierarchy (no directories) |
| 11 | +- tags |
| 12 | +- everything is a note or blob |
| 13 | +- every change is tracked and saved |
| 14 | + |
| 15 | +Normally in Zettelkasten, timestamps are used as identifiers. Zit deviates from |
| 16 | +this as timestamps are not very ergonomic to type, autocomplete, or |
| 17 | +disambiguate. Zit instead uses an identifier system that combines two lists of |
| 18 | +user-supplied identifiers to generate unique combinations. Here's an example: |
| 19 | + |
| 20 | +- user supplies two lists |
| 21 | + - list a |
| 22 | + - red |
| 23 | + - green |
| 24 | + - blue |
| 25 | + - list b |
| 26 | + - apple |
| 27 | + - banana |
| 28 | + - orange |
| 29 | + - possible identifiers |
| 30 | + - red/apple |
| 31 | + - red/banana |
| 32 | + - red/orange |
| 33 | + - ... |
| 34 | + - blue/orange |
| 35 | +- as new zettels are created, new and unused combinations are used to generate |
| 36 | + new identifiers that are then assigned to the zettel |
| 37 | + |
| 38 | +# naming of components |
| 39 | + |
| 40 | +If you make the mistake of looking at the code and trying to make sense of it, |
| 41 | +you'll notice something pretty quickly: there are a lot of bizarre names: |
| 42 | + |
| 43 | +- Akte: file |
| 44 | +- Angeboren: congenital config (*cannot* be changed after init) |
| 45 | +- Bestandsaufnahme: inventory list (like a git commit) |
| 46 | +- Bezeichnung: description |
| 47 | +- Erworben: acquired config (*can* be changed after init) |
| 48 | +- Etikett: tag |
| 49 | +- Gattung: genre (of the object that is being stored) |
| 50 | +- Hinweis: identifier for a Zettel chain |
| 51 | +- Kasten: repo |
| 52 | +- Kennung: identifier |
| 53 | +- Konfig: configuration |
| 54 | +- Metadatei: metadata |
| 55 | +- Objekte: object |
| 56 | +- Schlussel: key |
| 57 | +- Schlummernd: "sleeping or dormant", objects that are hidden from ordinary |
| 58 | + queries and must be explicitly recalled using the `?` operator, or |
| 59 | + explicitly recalled using their direct `Kennnung` (id) |
| 60 | +- Schnittstellen: interface |
| 61 | +- Sku: stock-keeping unit, representing an entry in a Bestandsaufnahme |
| 62 | +- Standort: directory (all directory operations are consolidated here) |
| 63 | +- Typ: type |
| 64 | +- Umwelt: environment |
| 65 | +- Verweise: refs |
| 66 | +- Verzeichnisse: cache / index |
| 67 | +- Zettel: note / object |
| 68 | + |
| 69 | +The above non-exhaustive list captures some of them. These are all |
| 70 | +google-translate looked up names of I've used to describe components of |
| 71 | + |
| 72 | +# directory structure |
| 73 | + |
| 74 | +## top-level |
| 75 | + |
| 76 | +I originally wrote this project in Go. However, as the project has grown larger, |
| 77 | +I've bumped into some of Go's tradeoffs that have led me to attempt rewriting |
| 78 | +small parts of Zit in Rust. |
| 79 | + |
| 80 | +## per-edition |
| 81 | + |
| 82 | +Besides the entrypoints (e.g., main.go, main.rs), each edition uses a strategy |
| 83 | +for forcing modularity and unidirectional dependencies like so: |
| 84 | + |
| 85 | +- zit/go/zit |
| 86 | + - main.go |
| 87 | + - src/ |
| 88 | + - alfa |
| 89 | + - errors |
| 90 | + - bravo |
| 91 | + - files |
| 92 | + - charlie |
| 93 | + - file_lock |
| 94 | + |
| 95 | +In the above selection, code in the `file_lock` module may depend on anything at |
| 96 | +the `alfa` and `bravo` levels. Code in the `files` module may depend on anything |
| 97 | +at the `alfa` level. And code in `alfa` may only depend on stdlib or external |
| 98 | +modules. |
| 99 | + |
| 100 | +For the code "levels", the NATO-phonetic alphabet is used. The benefits of this |
| 101 | +approach are it encourages modularity and creating a pyramid-like structure of |
| 102 | +dependency. For languages like Go, circular dependencies are not allowed and so |
| 103 | +this approach prevents hard-to-untangle dependency refactors. For Rust, this |
| 104 | +approach may help with build-times. |
| 105 | + |
| 106 | +# how do I use it? |
0 commit comments