canonical / canonical/concierge

Reconsider the "restore" approach

Open
#236 2 comments 0 reactions 0 assignees View on GitHub
needs design
Dominant language
Go
Stars
17
Forks
11
Avg merge
2d 3h
Merged PRs (30d)
6

Description

Restore is quite destructive, it just blindly undoes whatever the prepare would do. It might remove packages already in place, config that's been edited, and so on. We call this out in the docs, and concierge isn't really intended to be run somewhere where you are manually involved with the system. However, there is some risk here.

Maybe we should rename restore so it's more clear? It's deliberately matching spread, though.

Maybe we should put in a `-y` type mode and otherwise ask? This would have to be a major bump.

Maybe we should at least track better what prepare does and only remove when it's exactly what we did then? This could include storing hashes of files we create or update.

Maybe there are other ideas about a better / safer experience here.

Contributor guide

Open the contributing guide

Research direction

Start by tracing how the prepare and restore operations are implemented; the issue provides no file names, tests, or entry points. Compare the possible safety approaches and clarify the intended behavior and acceptance criteria with maintainers before making changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.