Environment:
- Base commit: ff905ef4
- Claude Code, Opus 4.7 for planning, Sonnet 4.6 for implementation
First prompt to add jj file edit:
Add a new command `jj file edit` which opens the user's editor with the
contents of a file at a particular revision. The command should take the
following options:
* `-r`/`--revision`: The revision in which to edit the file
* `--restore-descendants`: Same effect as this flag on `jj restore`: Whether
the difference should be merged into descendants or if they should preserve
their existing trees.
* `PATH` (as a positional parameter) The file to edit. For now only opens a
single file, but eventually this could accept multiple and the editor could
either open the whole directory, or jj could invoke the editor file-by-file.
The editor is opened with the contents of `PATH` at the given revision.
When the editor exits, the file is read and is overwritten in the given
revision and descendants are rebased on top of the rewritten commit.
Add the appropriate tests for this feature. Follow the existing naming
conventions, follow the existing testing patterns.
Then I skimmed the result without really reading it, as one does in this world of probababilistic software, and noticed it seemed to bail out if the file is conflicted.
If the file is conflicted in the revision, the user should still be able to edit
it. It should contain the materialized conflict markers, and editing them should
have a similar effect as editing conflict markers in the working copy has.
I skimmed again but didn't try very hard. I did manually clean up some doc comments, though (Claude copied explanation from my prompt and so they were awkward and verbose).
Finally, I decided to add jj file set:
Add a new command `jj file set` which receives file contents on stdin and
amends a file in the given revision. It takes the following options:
* `-r`/`--revision`: The revision in which to edit the file, default '@'
* `--restore-descendants`
* `PATH` (as a positional parameter) The file to update.
Descendants are rebased on top of the rewritten commit.
Example usage:
\```
echo "this is the new file contents" | jj file set -r xyz path/to/file.md
\```
Add the appropriate tests for this feature. Follow the existing naming
conventions, follow the existing testing patterns.