# ADR-0097: Discarding a rename restores the old name

- **Status:** Accepted
- **Date:** 2026-09-11
- **Deciders:** jka
- **Decision:** D97

## Context

A rename is the one change git records as one entry with two names. Discard (ADR-0080)
treated it as a change to the new name only: `git restore --staged --worktree -- new.txt`
dropped the index entry and left the file untracked, and the old name stayed deleted.
The rename was unstaged, not undone. The cause was the query: git's rename detection
needs both paths in the same diff, and a status narrowed to the new path reports a plain
addition.

## Decision

- `rio::git::discard` reads the full repository status and finds the entry, instead of
  querying the single path.
- For a rename (`R`): unstage both paths, restore the old name from the index into the
  working tree, then remove the new file with `git clean`.
- A copy (`C`) is handled as an addition: the new file is removed and the source is
  untouched.
- The function returns `{action, paths}`, so the operation emits `fs.changed` for both
  names (ADR-0094).
- In the git pane, the confirmation for a rename says the file will go back to its old
  name and last committed contents. The file tree's entry keeps the generic wording,
  because its rows do not carry the original path.
- `git.diff` uses the same full-status lookup for staged renames and passes git both
  names, so a rename shows as a rename rather than as a new file. Unstaged diffs are
  unaffected.

## Consequences

- Discard undoes a rename completely.
- The core is the authority on what a change is. A second frontend gets a correct diff
  and discard without knowing about renames.
- Clicking a staged row costs one full `status` call. The unstaged path does not.