Enhancement: Git-based undo/recovery system for operations

[bm-claudeai]

Summary

Implement Git-based undo/recovery mechanisms to provide users with safe operation rollback capabilities.

Background

From testing feedback: "Missing Undo/Recovery Mechanisms - No way to undo file moves, bulk edits, or other destructive operations. User mistakes can cause data loss or organization problems."

Proposed Solution

Leverage Git for operation history and recovery, aligning with Basic Machines' philosophy of using proven technology and maintaining local-first control.

Potential Features

• git_checkpoint("description") - Create named checkpoints before major operations
• git_undo() - Revert last operation
• git_history() - Show recent changes with operation descriptions
• git_recover(checkpoint_id) - Go back to specific point
• Automatic checkpoints before bulk operations

Benefits

• Leverages proven, robust Git infrastructure
• Keeps everything local and under user control
• Provides granular history tracking
• Enables powerful recovery scenarios (branch-based experiments)
• Reduces user anxiety about making mistakes

Implementation Considerations

• Integration with existing MCP tools
• User interface for browsing operation history
• Automatic vs manual checkpoint strategies
• Handling of large-scale operations

Priority

Medium - Enhancement for user confidence and workflow safety

Related

• Would pair well with bulk operations (#TBD)
• Could integrate with existing sync mechanisms

[pinkasey]

This is extremely useful and even required, IMHO.
I'm just starting to use LLM memory-manager (and I picked basic-memory), and 5 minutes into using it I realized I HAVE to have a mechanism for checkpoints, and git was my first choice. Exactly for the reasons listed -

• the LLM could easily mess up the memory in one prompt, and you want to be able to go back
• we already know git, git is powerful private and free.

[pinkasey]

@phernandez
I might try to implement this feature (I read the CONTRIBUTE.ms).

WDYT?
If I come up with a good implementation, is there a chance of adopting it?

[phernandez]

Hi @pinkasey If you have a need for git and want to give it a shot, that's great. I certainly have some thoughts about it w/regard to Basic Memory. The reason I haven't started on it is because there hasn't been an obvious way to handle when to commit.

• commit on every change?
• commit every so often, how often?
• push to a remote?
• how to handle conflicts?

Also some people use Basic Memory with tools like Claude Code that has hooks, and that can easily integrate git, so I think that's been a work around.

But I agree it would be something very valuable, particularly in collaborating with other people.

Here's a design spec I have. You are free to use it as a reference or go your own way. If you want to join our discord, you can dm me there. https://discord.com/invite/tyvKNccgqN. -- paul__h

SPEC-14- Cloud Git Versioning & GitHub Backup.md

[pinkasey]

Thanks!
I appreciate the quick answer
(the answer at all, TBH. I got so used to unmaintained, unresponsive SSOs. From time to time I still get responses on issues I've opened years ago).

If I get to invest in it - I'll follow the spec.
In the meantime I started working manually with git, committing and pushing manually
(I think of adding instructions for Claude to use the git MCP to commit and push after changes)

I'll give my own 2 cents on the issues you brought up, I also thought of some of them -

• commit on every change?
  • configurable. I was thinking of adding configuration like commitThresholdLines and set it to the number of lines that need to change in order to commit. there can be other similar configurations.
• commit every so often, how often?
  • same, I think it should be configurable. I think by default it should commit if there's a change that is 10+ minutes old
• push to a remote?
  • IMO, by default - yes, every commit. Most users will use this privately.
• how to handle conflicts?
  • I think the MCP should communicate them to the client, to notify the user. more specifically - I think some operations (write operations) should initiate a push. and then the error message can be added to the output.

[phernandez]

re: pushing to remotes. One idea I had, similar to how flutterflow 1 works, is to always force push to a named branch on the remote, like basicmemory, then the user could have the latest from the cloud, but deal with conflicts on their own.

[pinkasey]

Interesting.
I'm not sure I fully understand (what branch would the user be? main? basicmemory? and what if the user uses 2 different clients - both would push to basicmemory, and one would override the other)

It made me think of a similar approach -
A single user can use multiple clients (Claude Desktop, vs-code, ChatGPT desktop, different devices...)
Each client the user uses will have a dedicated branch, configurable locally (e.g in Claude-Desktop configuration).
For example - pinkasey/laptop/claude_desktop, phernandez/laptop/vs_code, etc.
So each client can push to its own branch without interference (ideally), and also try eagerly to merge their branch to main