It would be nice if snapshots could be expended with ^, ~N semantics.
If I restic restore latest --include /path/to/target --target . and the latest file is not the correct one, it is a sizeable exercise to figure out the previous snapshot. In git, HEAD^ conveniently means “the commit before the current commit”
That reminds me of Snapshot ID syntax to select parent snapshot · Issue #4122 · restic/restic · GitHub . Properly implementing such a snapshot selection is unfortunately more complicated than it appears to be, see the issue for more details.
idk if I should comment here or there, so I’ll avoid polluting the issue:
What if, instead of removing a snapshot, you make it 0-sized (or 0-contents)?
Then you can call it “deleted” (still maintaining the order).
Or, you can do a rebase (which ofc changes the snapshots).
Finally, I don’t “particularly care” for a “complete model change”.
In my eyes, latest^ is: restic snapshots, and then find which one is latest (i.e., the top one), and then move one down.
… ofc that means fetching more data - but I’ll do it anyway with restic snapshots. For a porcelain command, it’s expected.
0 sized snapshots are treated are considered to be invalid. This serves as a consistency check for broken backends. Furthermore, the filename of a snapshot is the sha256 hash of its content. Thus any change would either corrupt the snapshot or require a filename change. Either way the parent snapshot can no longer be resolved.
This would be rather complex to implement (as we’d have to rebase parent snapshots first) and it might run into certain race conditions once restic implements two-phase pruning (planned for 0.19.0), which would increase complexity further. Rewriting snapshots also increases the risk that the snapshots are damaged in the process.
In a nutshell, I don’t think that modifying snapshots is the right thing to do here. Some reliable way to group snapshots after the fact is much more promising here.