Editing this Wiki

Editing this Wiki

What this page covers: how to edit, commit, and push these wiki pages — the wiki is a separate git clone living inside the main checkout (gitignored by 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 wiki clone (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 separate repos and are versioned independently — 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 separate clone

The wiki is the GitHub wiki at https://github.com/EverNife/EveryDatabase.wiki.git, checked out as a standalone git repository in the wiki/ directory inside the main checkout. It is not a git submodule (there is no .gitmodules): the main repo simply ignores the directory — /wiki/ is in the main repo's .gitignore. Consequences:

• wiki/ has its own .git, its own history, its own HEAD, its own remote (the wiki repo).
• The main repo doesn't track the wiki at all — no files, and no pinned commit pointer. git status in the main repo never mentions wiki/; the two repos know nothing about each other.
• You clone the wiki separately (see below) into wiki/, and commit/push it entirely on its own.

flowchart LR
    M["EveryDatabase (main repo)"] -.->|"ignores /wiki/"| W["wiki clone<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 has no wiki/ directory (it's gitignored, not tracked). Clone the wiki repository into it yourself:

git clone https://github.com/EverNife/EveryDatabase.git
cd EveryDatabase
git clone https://github.com/EverNife/EveryDatabase.wiki.git wiki    # separate clone into wiki/

Because /wiki/ is in the main repo's .gitignore, the nested clone never shows up in the main repo's git status — the two repos stay completely independent.

⚠️ Gotcha — the GitHub wiki's default branch is master. If a git push complains there's no upstream, make sure you're on it: cd wiki && git checkout master.

---

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.

---

The main repo is not involved

Pushing inside wiki/ publishes your pages immediately — that alone updates the live GitHub wiki. There is nothing to do in the main repo: it ignores wiki/ entirely, so there's no submodule pointer to bump and no parent commit to make.

📌 Note — everything lives in the wiki clone. Because /wiki/ is gitignored, a stray git add -A in the main repo won't pick up your Markdown, and the main repo's git status stays clean. The one thing that publishes your changes is the git push from inside wiki/.

---

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.1.0, 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.