Diff Review

Every change Dino proposes goes through the diff viewer before it touches your files. This is the core of Dino’s safety model — you see exactly what’s changing, you give feedback where needed, and nothing applies without your sign-off.

The diff viewer is also the primary interface for the iterative workflow: review Dino’s proposed changes, leave inline feedback where something isn’t right, and send it back for revision. Repeat until the changes are exactly what you want. For the design thinking behind this approach, see Design Philosophy.

How the Staging Layer Works

Dino edits files in a virtual staging layer, not on disk. Think of it as a scratch space for proposed changes:

1. Dino reads your codebase and proposes edits
2. All edits accumulate in the staging layer as a changeset
3. The diff viewer shows you the changeset — additions, deletions, and modifications
4. You review, comment, revert, or approve
5. Only when you click Apply to Disk do changes get written to your filesystem

The staging layer persists across turns within a conversation. If you ask Dino to make additional changes, they stack on top of the previous ones. You can review the cumulative diff at any time.

Opening the Diff Viewer

The diff viewer doesn’t open automatically — you open it when you’re ready to review:

• Click Review Changes in the uncommitted changes block in the chat
• Click the changes indicator in the top bar (e.g., “2 files changed”)
• Click “View Changes” on any commit block in the conversation

Navigating Changes

Once the diff viewer is open, you can navigate between individual changes:

Action	Control
Next change	↓ or j
Previous change	↑ or k
Jump to file	Use the file picker in the header

The footer shows your position: “Change 3 of 12” — so you always know how much there is to review.

Inline Comments

You can leave comments on any individual change in the diff. Comments are sent back to Dino as feedback, so it can revise its approach.

1. Click on a change in the diff
2. Type your comment (e.g., “Use a Set instead of an array here” or “This breaks the existing API contract”)
3. Save the comment

You can add multiple comments before sending them all at once.

Selective Reverts

If Dino proposes a change you don’t want, you don’t have to reject the entire changeset. Instead:

1. Toggle the revert checkbox on any individual change
2. The change is marked for removal
3. When you apply or send feedback, those changes are reverted from the staging layer

This lets you cherry-pick — accept most of a changeset while discarding specific parts.

Send Feedback

The Send Feedback button sends all your inline comments and reverts back to Dino as a new prompt. Dino reads your feedback and generates a revised changeset that:

• Addresses your inline comments
• Respects your reverts (it won’t re-apply reverted changes)
• Preserves changes you didn’t comment on or revert

This creates a tight feedback loop: propose → review → feedback → revise, until you’re satisfied. This iterative cycle is the primary way to work with Dino — you don’t need to get the prompt exactly right on the first try.

Apply to Disk

When you’re happy with the changes (or want to test them):

Apply to Disk — Writes all changes in the changeset to your filesystem. Your working directory is updated, but no git commit is created. This is useful when you want to run tests or verify behavior before committing.

Apply & Commit

If your project uses git, you can apply changes and commit in one step:

1. Click Apply & Commit…
2. Dino auto-generates a commit message based on the diff (you can edit it)
3. Optionally include a Co-authored-by: Dino trailer
4. Confirm to apply changes and create the commit

The commit is created on your current branch with whatever git user is configured.

Viewing Past Commits

You can revisit changes from any commit in the conversation. Click “View Changes” on a commit block to open the diff viewer in read-only mode. Historical diffs show a banner indicating you’re viewing committed changes from history.

Rebase

When your base branch advances — someone else pushes new commits, or you apply changes from another Dino tab — Dino detects the conflict and shows a rebase banner. This means your staged changes may conflict with the new upstream state.

To resolve:

1. Click Rebase in the rebase banner
2. Dino attempts an automatic rebase of your changes onto the new base
3. If conflicts arise, Dino sends the conflict to the model for resolution — it reads both versions and produces a merged result
4. Review the resolution, then apply when you’re satisfied

Since all changes live in memory until you apply, there’s no risk of data loss during a rebase. The worst case is a messy merge that you can simply discard.