mirror of
https://github.com/runbear-io/beardrive.git
synced 2026-08-25 08:08:08 +02:00
Snow Lee (Sungwon)andGitHub
709c40e76c
Clicking `restore` in History posted straight to the hub — no dialog — while the two other web actions that leave the browser (revoke a share link, remove a file) both confirm first. The gated action was the reversible one and the effectively-irreversible one wasn't. The dialog's second line is case-aware, because the two cases really do differ: swapping a live file's content is walk-backable from History, but bringing a deleted file back is not — the run card's "undo — remove file" is the only delete control in the whole web UI, and a restore produces no run card. So that branch says so instead of promising an undo the UI can't keep. The flag needs no new computation: headBlob's "" already marks a path whose newest op is a delete, so HistoryView passes `recreates` down beside `restoreSha` (both feed shapes — standalone rows and rows inside a run card). A row can't decide this itself: an older EDIT row of a deleted path re-creates the file just as much as the DELETED row does, and only the feed knows that. Confirm styling is non-danger on purpose: restore adds content, it takes none away, so it doesn't wear Remove's red. Building the missing undo for the ADDED row a restore creates is deliberately out of scope (Snow scoped this to "add confirmation").