Git

The Git plugin reads what the repository knows about the project. It keeps the project’s versions, eidos git version, and writes the tag a 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 project is inside a repository, off outside one.

In the app

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 project (git status over the project 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. An eye on a change’s row opens the file’s page, and the repository’s commits sit below, each opening its own 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 project’s to word, as Commit convention under Commit messages on this plugin’s page.
Fetch, when the branch has a remote, reads what the remote holds without changing anything under the project. 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 brings the branch level with its upstream the way you pick from the menu on its button: Fetch All (every remote fetched, nothing pulled), Pull (fast-forward if possible), the default, which makes a merge commit where your branch and the upstream have each moved on, Pull (fast-forward only), which refuses then in git’s words, and Pull (rebase), which replays your commits on top. The kind you pick runs at once and is what Pull runs from then on, kept as pull_kind in your preferences.yaml. Uncommitted changes are stashed and put back around every kind, so they never refuse a pull; where they clash with what was pulled, git keeps them in the stash list and the files are listed to resolve.
Conflicts: a pull that stops on conflicts, or any merge or rebase that does, shows in Source control with Continue (offered once every file is resolved) and Abort (asked once, putting the branch back as it was), and lists each conflicted file. A file opens in the built-in diff viewer as Your changes against the upstream’s, named for you even where a rebase swaps git’s sides, with Take mine, Take theirs, Edit to fix it by hand, and Mark resolved, refused while conflict markers remain. Where the AI Agent is on, Resolve with AI asks it for the resolved file and shows its answer as a diff, written only when you Accept it.
A commit’s page: Source control’s Commits read as a history, each the subject over the author’s avatar and name and how long ago, with Show more past the last 50. A commit opens as a tab with its subject, its body, its author, the sha to copy, and the lines added and removed over the files it changed, each with its mark, and the picked file’s diff against the commit’s parent (a project commit against nothing, a merge against its first parent). A row in File history opens the same page with that file picked.
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 palette: Git: Commit commits every change under the project at once, with the AI Agent’s one-line summary as the message when it is on and a plain list of the files when it is off or does not answer. Git: Publish and Git: Fetch run Source control’s own Publish and Fetch, without the AI Agent. Each says how it went in a toast: what was committed, where it went, or why it did not (nothing to commit or 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 project 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 project’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 git version runs, and a tag changes in this repository alone. With the Keep versions switch off, on the plugin’s page, the activity, the page, and its palette commands are gone.
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 project 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 view and no branch switching, and a merge or rebase starts only as a pull.

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.
.eidos/plugins/git/settings.yaml, shared with the project: versions, on unless set to false, which turns Versions off for everyone (the Keep versions switch on the plugin’s page: no Versions activity, page, or command, and no version check; the record and its tags stay as they are), and commit_prompt, the project’s commit message convention.

The plugin keeps no other file.

From the shell

The repository is read with git itself. What the plugin adds to the CLI is eidos git version, the project’s recorded versions: the commit a version names, and its tag made, moved, or deleted, never pushed.

eidos git version                                   # the project's versions, newest first
eidos git version record 1.0.0                      # a row naming HEAD
eidos git version record 1.0.0 --commit a1b2c3d --tag   # names that commit and tags it blueprints/1.0.0
eidos git version set 1.0.0 --name 1.0.1            # renames it; its tag follows
eidos git version remove 1.0.0 --tag                # takes it out and deletes its tag here
eidos plugin set git versions false                 # turns Versions off for the project
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, or Versions off, each of these says so and how to turn them on. eidos version is the versions of eidos itself, so eidos version record and eidos version set only say to use eidos git version. eidos git version →

What the check reports

The project’s versions against the repository’s tags, as warnings on .eidos/plugins/eidosmd/versions.yaml, each naming the eidos git version commands that settle it, while Versions are on: 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.