Source Control

Stage, commit and discard your Git changes from a sidebar panel, and read your project's history as a branch graph in the same place.

What you can do

• See your working-tree changes split into Staged and Changes lists
• Stage or unstage files one at a time or all at once
• Write a commit message and commit your staged changes
• Have the active AI core write the commit message from what you have staged
• Discard changes to a file (asks you to confirm first)
• See exactly what changed in a file, line by line, before you commit it
• Follow your history as a graph, with a lane per branch and a line into every merge
• Give the graph more of the panel, or less, by dragging the line above its header
• See what any commit changed, and open one of those files as it was then
• Start tracking a folder that isn't a Git repository yet

The graph

The Graph at the bottom of the panel draws your history the way it happened: one lane per line of development, a curve where a branch left and another where it came back, and a ring on the commit your working tree is sitting on. Branch and tag names appear on the commits they point at, and a remote that agrees with a local branch shows as a small cloud rather than repeating the name.

• Every ref, or just this branch. The chip in the graph header switches between all branches and tags and the branch you are on.
• What a commit changed. Click a row. The files appear underneath with the same letters the Changes list uses, and a merge shows what it brought in rather than everything either side did.
• The changes themselves. Click one of those files to open the commit's diff, scrolled to that file, with the untouched parts folded away until you ask for them.
• Hover for the rest. Author, both timestamps, the parents, the full hash to copy, and a way to switch to a branch that is sitting on that commit.
• As much of it as you want. Drag the line above the graph header to give the graph more of the panel or less, and where you leave it is where it opens next time.

It reads your repository and never writes to it. History is only re-read when something actually moved, so a graph left open costs nothing while you work.

Seeing what changed

Clicking a file's name — in Staged, in Changes, or under a commit in the graph — opens the diff in the editor area, never in the sidebar: a comparison needs the line and both of its line numbers, and a narrow panel has room for none of it. The file itself is still one click away, on the icon to the right of the name.

Every file in the tab shows its own additions and deletions and can be folded shut. The unchanged stretches between changes are collapsed to a line saying how many there are; click it to see them. A file that is new to Git shows as what it is, all additions, rather than as nothing at all.

The button in the tab's header switches between one column and two. Side by side puts the old file on the left and the new one on the right, each with its own line numbers, an edited line opposite the line it replaced, and the two halves scrolling together. Whichever you pick is remembered.

Commit messages written for you

The sparkle button inside the commit message box hands your staged changes to whichever AI core is active and puts the result in the box, where you can edit it before committing.

It reads the subject lines of your recent commits and learns their language, their prefixes and their tense, so the message comes back in your own convention rather than a house style. Your history teaches form only, never content. Subjects that describe nothing, like test or wip or update, are never shown to the model, and a message that comes back saying nothing is asked for again instead of landing in the box. Nothing leaves your machine unless the core you picked is a remote one. If no core is active, or the core you picked cannot write a message, the button says so and the panel carries on working.

Continuous integration for your MLOps pipeline

If your workspace has a pipeline in .punica/mlops.yaml, this extension turns it into a GitHub Actions workflow that runs the same checks the editor runs. Each gate's provider hands over the driver it already executes, so the two sides are the same code rather than two implementations that are supposed to agree.

• Generate the workflow. Writes .github/workflows/mlops.yml plus the gate files it calls. A stage that has no form outside the editor stops the whole thing: nothing is written, and you get the reason. A workflow whose second step does not exist is worse than no workflow.
• Check the two sides agree. Runs every stage twice, once the way the runner would and once as the pipeline's gate, and reports each one as agree, differ or could not be compared here.
• Read the remote status. Uses the GitHub CLI, which already holds your credentials, and always says which commit a run belongs to. A green run for a commit you do not have is not your work passing.
• Gate your pushes. Installs a pre-push hook that runs the pipeline's gates before a push. It runs the gates only, never the training stage. A gate that cannot run on your machine reports and lets the push through; a gate that fails stops it. git push --no-verify bypasses it, and a hook you already had is never replaced.

Secrets are never sent anywhere. The workflow checks that each one it needs is set and stops with the name of the missing one, and you are handed the gh secret set line to run yourself.

Getting started

Open Source Control from the activity bar in a Git repository. Your working changes are listed there.