Git

The Git plugin reads what the repository knows about the root. It writes the tag eidos version asks for (made, moved, or deleted in this repository alone, never pushed), the git mv or git rm behind a rename or delete, the commit, pull, and publish a person makes in Source control, and, only where you turn them on in your local settings, an auto fetch, an auto save, and its publish. On by default where the root is inside a repository, off outside one.

In the browser

• File history, a view in the Auxiliary Sidebar: the commits that touched the open blueprint, newest first, following renames, each with a Diff button that opens the commit’s version against the file now in the built-in diff viewer, or in this machine’s own viewer when one is set. A change in Source control opens the same way from its name, the last commit against the file now: a tab in the main area, side by side or inline, the changed words marked, unchanged lines folded, and arrows through the changes.
• Source control, an activity in the Activity Bar with the count of changes on its icon: what changed under the root (git status over the root alone), each path with its mark and a box ticked by default, a message, and Commit, which stages and commits the ticked paths and nothing else (git add -A -- <paths>, then git commit -m <message> -- <paths>). A rename commits the path it came from with it, and a deletion already staged (the page deletes through git rm) is committed as it stands. Git’s refusals are shown as git said them. The repository’s last 50 commits sit below, and an eye on a row opens the file’s page.
• Summarize, beside Commit when AI Agent is on, asks the AI Agent for a one-line message for the ticked changes and puts it in the box to edit or commit as it is. What the AI Agent is asked is the root’s to word, under Commit messages on the AI Agent’s page.
• Fetch, when the branch has a remote, reads what the remote holds without changing anything under the root. A row under Source control’s head appears only when there is something to do: how many commits there are to pull from the upstream (“2 commits to pull from origin/main”), a branch not yet on its remote, no fetch yet, or a fetch that failed, with Fetch beside it. Level with the upstream, there is no row, and Fetch is the arrow icon beside refresh in the head. Pull, there while there are commits to pull, fetches and then moves the branch up to its upstream only where that is a fast-forward: it never makes a merge commit or rebases, and when your branch and the upstream have each moved on, it says what git said and leaves the rest to your own tool.
• Publish, in Source control’s head when the branch has a remote, fetches and then pushes the branch to it (to its upstream, or to origin with the upstream set the first time), showing how many commits the remote has not seen as a small number on the button (99+ past 99). While the upstream holds commits your branch does not, Publish is disabled and the row under the head says to pull them first.
• From the Chat, with AI Agent on: /git-commit asks the agent to commit what changed under the root right away, the message in the style of the repository’s recent commits (anything you type after the command steers it), and to say what it committed. /git-publish and /git-fetch run Publish and Fetch at once, without the agent, and write the outcome into the conversation: where it went, or why it did not (nothing to publish, no remote, commits to pull first, git’s own refusal).
• Auto save, a local setting on the plugin’s page, commits every change under the root every 5, 15, 30, or 60 minutes, with the AI Agent’s summary as the message when it answers and a plain list of the files when it does not; with publish on, each one is pushed as it is made, after a fetch, and left unpushed while there are commits to pull, saying how many. The last one shows at the top of Source control. A commit or a push that waits on a signing key or a remote is stopped after a while and says so, and the page never waits on it.
• Auto fetch, a local setting on the plugin’s page, fetches every 5, 15, 30, or 60 minutes, the first time soon after the server starts, so the count to pull stays current. Off by default. A fetch never stops to ask for a password, and on macOS and Linux not for a key’s passphrase either: a remote that needs one your credential helper or ssh agent does not give fails in git’s words.
• Versions, an activity in the Activity Bar, lists the root’s versions, and its page is a table of every version with its commit (its subject on hover; a click opens Source control), the commit’s date, and its tag. Record a version… takes a name, a commit picked from the recent ones (HEAD unless you pick another), and a switch for the tag. A row’s ⋮, or a right-click, renames it, points it at another commit, adds or deletes its tag, copies the commit, or removes it, asked once with a switch that deletes the tag too. Where the record and the repository’s tags disagree, the page says so above the table with a button for each fix. Every change runs what eidos version runs, and a tag changes in this repository alone.
• A comment nobody is acting as a listed user is signed by the git identity, matched to a listed user where one has that email. Comments →
• A rename or delete of a tracked file, from the page or the shell, is git mv or git rm, so history follows. An untracked path, a root outside a repository, or a git that refuses hands the operation back and a plain rename or delete follows.

A top-level doc, the framework document, and a canvas have no history view. There is no blame, no branch switching, and no merge or rebase: a pull only fast-forwards.

On disk

• .eidos/plugins/git/local.yaml: one person’s settings, set on the plugin’s page under local and never committed: diff_viewer, unset for the built-in viewer, or a command with {a} and {b} for the two files (code --diff {a} {b}), chosen as Built in or Your own command; auto_save, off or 5, 15, 30, 60 minutes; publish, whether each auto save is pushed; auto_fetch, off or 5, 15, 30, 60 minutes. An auto save never starts on a clone because someone else turned theirs on.

The plugin has no shared setting beyond its switch and keeps no other file.

From the shell

There is no eidos git: the repository is read with git itself. What the plugin supplies to the CLI is the git behind the recorded versions: the commit a version names, and its tag made, moved, or deleted, never pushed.

eidos version record 1.0.0                          # a row naming HEAD
eidos version record 1.0.0 --commit a1b2c3d --tag   # names that commit and tags it blueprints/1.0.0
eidos version set 1.0.0 --name 1.0.1                # renames it; its tag follows
eidos version remove 1.0.0 --tag                    # takes it out and deletes its tag here
git log --follow -- Blueprints/specs/login.md       # the commits that touched a blueprint
git show a1b2c3d:Blueprints/specs/login.md          # the blueprint as it was

With the plugin off, recording says so and eidos version lists what is recorded. eidos version →

What the check reports

The root’s versions against the repository’s tags, as warnings on .eidos/plugins/eidosmd/versions.yaml, each naming the eidos version commands that settle it: git/version-tag-missing, a tag a version names that the repository does not hold; git/version-tag-moved, one it holds on another commit; git/version-tag-stray, a tag under the prefix that no version names (none with a blank prefix). A shallow clone, as a CI checks out, holds only some tags, so there it reports none. Off, outside a repository, or without a git binary, the plugin answers empty, spawns nothing, and its page says which of the three it is.