Editing this Wiki

Editing this Wiki

What this page covers: how to edit, commit, and push these wiki pages — the wiki is a git submodule of the main repo, with its own remote — plus where the page conventions live so your edits stay consistent.

---

The 60-second version

# From inside the main EveryDatabase checkout:
cd wiki                                     # enter the submodule (its own git repo)

# ...edit / add Markdown pages...

git add Building-from-Source.md
git commit -m "Wiki: clarify the Jabel dual-target"
git push                                    # pushes to the wiki remote, not the main repo

That push goes to the wiki repository, not to the main project. The two are linked but versioned separately — see below.

📌 Note — page conventions (page shape, the four callout markers, code rules, English-only) are summarised below — follow them. Caching & References is the gold-standard example page to imitate for voice and depth.

---

Why it's a submodule

The wiki is the GitHub wiki at https://github.com/EverNife/EveryDatabase.wiki.git, vendored into the main repo as the wiki/ submodule. From .gitmodules:

[submodule "wiki"]
	path = wiki
	url = https://github.com/EverNife/EveryDatabase.wiki.git

A submodule is its own independent git repository living inside the parent. Consequences:

• wiki/ has its own history, its own HEAD, its own remote (the wiki repo).
• The main repo doesn't track the wiki's files — it tracks a single pointer: the exact wiki commit it's pinned to. That's why git status in the main repo shows wiki as a one-line change when the submodule moves, not a diff of the Markdown.

flowchart LR
    M["EveryDatabase (main repo)"] -->|"pins commit"| W["wiki submodule<br/>(EveryDatabase.wiki.git)"]
    W -->|"git push from inside wiki/"| GH["GitHub wiki remote"]

Loading

---

First-time setup

A fresh clone of the main repo leaves the submodule empty until you initialize it:

git clone https://github.com/EverNife/EveryDatabase.git
cd EveryDatabase
git submodule update --init wiki            # populate wiki/ at the pinned commit

Already cloned? git submodule update --init does the same retroactively.

⚠️ Gotcha — a freshly populated submodule is often in detached HEAD (checked out at the pinned commit, not on a branch). Before committing wiki changes, put yourself on the wiki's default branch so the push has somewhere to go: cd wiki && git checkout master (the GitHub wiki's branch). Otherwise your commit lands on a detached HEAD and git push has no upstream.

---

The edit → commit → push flow

Everything happens inside wiki/, which is its own repo:

cd wiki

git checkout master                         # ensure you're on a branch, not detached HEAD
# ...add or edit pages (e.g. New-Page.md)...

git add New-Page.md _Sidebar.md             # add the page AND link it in the sidebar
git commit -m "Wiki: add New-Page"
git push                                    # -> the wiki remote

When you add a new page, two things must travel with it:

1. The file, named to match its title (Editing this Wiki → Editing-this-Wiki.md). GitHub maps spaces in the title to hyphens in the filename and in the URL.
2. A sidebar entry in _Sidebar.md — navigation is manual; there is no auto-generated tree. The sidebar is the single source of structure and order. Use the exact titles there in your [[links]].

💡 Tip — wiki-internal links use [[Page Title]] (or [[Custom text|Page Title]]). The title must match the page's filename (hyphenation handled by GitHub). Link liberally — cross-linking is the spine of this wiki.

---

Recording the new wiki state in the main repo (optional)

Pushing inside wiki/ publishes your pages immediately — that alone is enough to update the live GitHub wiki. If you also want the main repo to pin the new wiki commit (so a clone of the project checks out these pages), commit the moved submodule pointer in the parent:

cd ..                                       # back to the main repo root
git add wiki                                # stage the new submodule commit pointer
git commit -m "Bump wiki submodule"

📌 Note — these are two separate commits in two separate repos: one inside wiki/ (your actual page edits, pushed to the wiki remote) and, optionally, one in the main repo (just the pointer bump). Forgetting the inner push is the classic mistake — the pointer would reference a commit that only exists on your machine.

---

Conventions, in one place

Don't reinvent the page style. The authoritative example is:

• Caching & References — the flagship worked example; match its voice, callout use, and See-also block.

The conventions in brief:

• Page shape: a one-line "what this page covers", then the smallest runnable example, then concept expansion with focused snippets, gotchas inline, and a ## See also block of [[links]].
• Callouts (exact markers): > 💡 **Tip** — …, > 📌 **Note** — …, > ⚠️ **Gotcha** — …, > 🧭 **Decision** — ….
• Versions live in exactly one page — Dependency Versions & Overrides. Pin artifact coordinates to 1.0.4, but never restate a dependency version elsewhere; link there instead.
• English only, matching the codebase convention.

---

See also

• Building from Source — the build the wiki documents.
• Running the Tests · Project Layout — the sibling Contributing pages.
• Dependency Versions & Overrides — the single home for version numbers.