Would appreciate clarification on checkpointing

When I revert to an earlier version of the codebase within a Composer session, all subsequent chat and code changes are grayed out. If I rewrite the prompt at the checkpoint I reverted to, the grayed-out sections below that checkpoint are removed, and a new chat continuation begins. This is useful for exploring different approaches and discarding the grayed-out versions of changes made after the checkpoint.

However, if I use the regular prompt box to continue working from the checkpoint I reverted to, will the changes and checkpoints between the last checkpoint and the new changes I make with the regular prompt box remain accessible for future reversion?

Also, would like clarification on another scenario. What if I checkpoint to a certain version of the code base in a composer and then start a fresh composer session and continue making changes and THEN go back to the original composer and check point to another state of the codebase - should that work fine and “undo” the changes made in the other fresh composer session?

I’m asking this because I done that and it didn’t really work well and broke the code.

1 Like

Hey,

For scenario 1, if you have reverted to a checkpoint, both the inline prompt box, and the normal one at the bottom will discard the messages after the checkpoint.

For scenario 2, checkpointing in an old composer should remove any changes since that point, including those in other composer sessions (which should be making their own checkpoints too!)

If I rewrite the prompt at the checkpoint I reverted to, the grayed-out sections below that checkpoint are removed, and a new chat continuation begins.

@danperks it would be really_nifty to bookmark a checkpoint and then be able to prompt from that checkpoint multiple variation cenarios nd compare result side by side in columns… and super_nifty to have dual composer columns from the checkpoint where left is model_a and right is model_b outcome for sms prompt with an ultra_nifty merge workflow.

And stretch_goal_nifty if content blocks can have a you decoration for which model generated something.

Whereby when an “apply” is saved some meta_dta_flag is invoked for saving created_by_model= is set even as a header comment in any saved output.

(Lemme see if I can rules that too…)