Fixes #4827: Create checkpoints before changes, not after

[roomote]

Summary

This PR fixes issue #4827 by modifying the checkpoint creation timing to occur before file changes are made instead of after. This allows users to revert to the state before changes were applied, which is the expected and more useful behavior.

Changes Made

Core Fix

• Modified all file editing tools to create checkpoints BEFORE applying changes:
  • (both batch and single file cases)
  • (legacy implementation)

Implementation Details

• Checkpoints are now created after user approval but before file modifications
• For batch operations in apply_diff, a single checkpoint is created before processing all approved files
• Added fallback checkpoint creation in for edge cases
• All checkpoint creation is conditional on cline.enableCheckpoints being true

Testing

• ✅ All existing checkpoint tests continue to pass (34/34 tests passing)
• ✅ No breaking changes to existing functionality
• ✅ Linting and type checking pass

Impact

• Before: Checkpoints captured the state AFTER changes, making them less useful for reverting
• After: Checkpoints capture the state BEFORE changes, allowing proper reversion to pre-change state
• Users can now effectively use checkpoints to undo file modifications

Fixes #4827

---

Important

Checkpoints are now created before file modifications in various tools, allowing users to revert to the pre-change state, with fallback mechanisms for edge cases.

• Behavior:
  • Checkpoints are now created before file modifications in writeToFileTool, applyDiffTool, insertContentTool, and searchAndReplaceTool.
  • For batch operations in multiApplyDiffTool, a single checkpoint is created before processing all approved files.
  • Added fallback checkpoint creation in presentAssistantMessage.ts for edge cases.
• Implementation:
  • Checkpoints are created after user approval but before file modifications.
  • All checkpoint creation is conditional on cline.enableCheckpoints being true.
• Testing:
  • All existing checkpoint tests continue to pass (34/34 tests passing).

^{This description was created by for c7a1651. You can customize this summary. It will automatically update as commits are pushed.}

[mrubens]

@cte does this PR look right to you?

[cte]

@roomote I would expect this PR to also remove the existing logic that saves checkpoints after changes have been made. Can you find where we're doing that and see if we need to make any changes there? Also, I think the pre-existing logic only needs to call saveCheckpoint in a single place, whereas this PR seems to call it in a bunch of places; is it possible to hook in at a single place (prior to changes being made)?

[ellipsis-dev]

⚠️ This PR is too big for Ellipsis, but support for larger PRs is coming soon. If you want us to prioritize this feature, let us know at [email protected]

---

Generated with ❤️ by ellipsis.dev

[cte]

@roomote Please remove the unnecessary comments in this PR.

[ellipsis-dev]

⚠️ This PR is too big for Ellipsis, but support for larger PRs is coming soon. If you want us to prioritize this feature, let us know at [email protected]

---

Generated with ❤️ by ellipsis.dev

[daniel-lxs]

A few suggestions:

1. Consolidate checkpoint logic in multiApplyDiffTool - The checkpoint creation is duplicated in multiple places (lines 306, 350, 379). Since we now have centralized checkpoint creation in askApproval, consider refactoring multiApplyDiffTool to use the standard approval flow.

2. Optimize isFileEditingTool check - This check runs for all tools, not just file-editing ones. Minor inefficiency but worth addressing.

3. Extract file-editing tools list - The array ["write_to_file", "apply_diff", "insert_content", "search_and_replace"] could be a reusable constant.

Also something to keep in mind, if creating more checkpoints is making the file edit tools take longer we might want to update the timeout on the e2e tests.

[KJ7LNW]

+1

please make sure the user interface shows the rollback icon in the correct location.

it would be nice if you show a dotted horizontal-rule as the "line in the sand" for where it gets reverted for extra clarity because exactly where it reverts based on the icon is somewhat hard to figure out

only show the horizontal rule if the mouse hovers