Color scheme: Riviera
You are here: start » en » Documentation » DokuWiki extensions (WvdS) » Git » Quickstart: register the first local repository

Quickstart: register the first local repository

The shortest way from “the plugin is installed” to “a repository on the server's disk reports ok and shows branches, tags and commits in the wiki”. Four steps, about ten minutes.

To draw the line: this plugin reads repositories in the server's file system through the git program. Repositories hosted in Azure DevOps are served by wkdoadogit.

Prerequisites

  • wkdogit, wkdocore, wkdostorage and wkcore are installed and enabled.
  • git is installed on the server, and the user PHP runs as may execute it.
  • A repository on that server's disk, readable by the same user.
  • Optional: wksourceview, so files can be embedded on pages.

Step 1: name the binary

Admin → Configuration, section wkdogit, setting git_binary. It is empty by default, so nothing works until it is set.

Enter an absolute path — on Linux something like /usr/bin/git, on Windows the full path to git.exe.

A bare git is deliberately not looked up on the search path — otherwise whatever comes first there under the name git would run. The plugin finds no file and reports itself unavailable.

A wiki that carries its own Git, on a USB drive for example, enters a path relative to the wiki directory: ../server/git/{os}/bin/git. {os} becomes windows, linux or macos.

On this installation git_binary is git. A bare name is never looked up on the search path, so wkdogit starts no Git here and reports itself unavailable.

Step 2: confine where repositories may live

Set git_repo_root to the directory holding them.

A relative value is taken from the wiki's data directory: repositories means the folder of that name next to pages and media. If the directory does not exist, the plugin admits no repository at all — a typo locks things down instead of lifting the boundary.

This setting bounds which paths may be registered and used. Set it before registering anything: it decides whether “a repository path” means one of yours or any path on the machine. On this installation it is empty, so unconfined.

Step 3: check the web server can actually read it

A repository you may read is not necessarily readable by the web server's user. This is the commonest first failure and it has nothing to do with the plugin.

Confirm that the user PHP runs as can read the repository directory and its .git contents.

Step 4: register and check

Open the project's repos screen, for example /doku.php?id=en:projects:acme:repos&do=wkdogit.

Fill in under Register repository: Key, Title, Local path (inside the root from step 2) and Default branch. A local path or a remote URL is required; a remote URL must not contain credentials.

Choose Register, then Healthcheck on the row.

Check the result

  • The Health column reads ok. When it reads otherwise — unreachable, invalid or denied — it is naming the reason rather than just a failure: missing binary, path outside the root, unreadable directory, or something that is not a repository.
  • The opened repository shows Branches, Tags and commits.
  • Every call is bounded by git_timeout_ms, 5000 milliseconds by default. A very large repository can reach that limit on its first listing; the answer usually lies with the repository rather than with the setting.

Next step

  • wksourceview — show a file from it on a wiki page, through the git: provider.
  • wkdogit (German) — the package page: the read model, the verb allowlist and all five settings, among them max_bytes and max_lines, which deliberately mirror the source viewer's own.
en/wiki/dwe/wkdogit/quickstart.txt · Last modified: by 0.0.0.0