[WIP] Checkpoints

[cte]

Description

Currently Cline has a nice "checkpoints" feature (see demo) that allows you to revert your VSCode workspace to a point in time in the chat history. It doesn't this by creating a "shadow" repository that is completely isolated from the current repo (if any).

An alternative approach that I'm exploring here is to use a separate branch to more space efficiently store checkpoints that can be restored using git restore.

I consulted o1 Pro about the differences between these approaches, and here's what it thinks:

1. Quick Summary of the Approaches

“Hidden/Worktree Branch” in the Same Repo:
Pros
• Integrates directly with the user’s existing repository, so merges, logs, and reverts can all happen in one place.
• No duplication or copying files out to another folder—Git takes care of the branching/worktree logic.
• If the user is Git-savvy, they can see the AI commits or bring them into main with a normal merge.

Cons
• Potential to “pollute” or complicate the user’s main repo with ephemeral commits unless carefully managed (hidden branch, separate worktree).
• If you do the stash/unstash approach, you risk conflicts and stash merges in the user’s main environment.

“Shadow Repo” (Entirely Separate .git):
Pros
• Completely isolates the user’s main repository from the AI checkpoint logic. There’s zero chance of messing up or cluttering their primary .git or branches.
• You don’t need the user’s main workspace to be under Git at all. Your extension has full control over the “shadow” .git.
• It can be simpler in the sense that you own the entire flow: no stashing, no merges to user branches, no prying into user commits.

Cons
• You’re effectively maintaining two parallel copies of the user’s code. You must keep them in sync if your AI or the user wants consistent states.
• Reverting from a checkpoint means copying those versions back into the user’s workspace. If the user made manual edits in the meantime, you might end up overwriting them or writing a custom merge routine.
• It’s not integrated with the user’s normal Git history. They won’t see these AI commits with git log in the main project.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Checklist:

• My code follows the patterns of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation

Additional context

Related Issues

Reviewers

[changeset-bot]

⚠️ No Changeset found

Latest commit: 411e1ff

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[cte]

Fixes the following warnings:

$ npm test

jest-haste-map: duplicate manual mock found: McpHub
  The following files share their name; please delete one of them:
    * <rootDir>/src/__mocks__/McpHub.ts
    * <rootDir>/out/src/__mocks__/McpHub.js

jest-haste-map: duplicate manual mock found: fs/promises
  The following files share their name; please delete one of them:
    * <rootDir>/src/__mocks__/fs/promises.ts
    * <rootDir>/out/src/__mocks__/fs/promises.js

[cte]

Useful for nix users to instantly create the development environment needed to run Roo Code:

• https://nixos-and-flakes.thiscute.world/development/intro

[cte]

Should we be locking the Node version in somewhere? (Like package.json#engines).