-
Notifications
You must be signed in to change notification settings - Fork 291
implement moveTo and rename
#6054
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Successful moves now show "Moved:" with aligned arrows Conflict case shows the new wording: "I couldn't move some of the items, because they had the same final segment as some of the others, meaning that they would have ended up with duplicate names at the destination:" Numbered list of conflicting items "You can rename them and then use moveTo again, for example:" Example rename and moveTo commands
since it's semantics are changing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR implements two new commands, moveTo and rename, that provide convenient ways to reorganize code in the Unison codebase. The moveTo command moves one or more items into a destination namespace while preserving their final name segments (e.g., moveTo foo.bar dest produces dest.bar). The rename command changes only the final segment of a name within the same parent namespace (e.g., rename foo.bar.baz Qux produces foo.bar.Qux).
Key changes:
- Added two new command handlers (
MoveTo.hsandRename.hs) that implement the core logic for moving and renaming definitions - Updated command definitions and help documentation to include the new commands
- Implemented conflict detection for
moveTowhen multiple sources have the same final name segment
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| unison-src/transcripts/idempotent/move-to-and-rename.md | Comprehensive transcript demonstrating both commands with various scenarios including error cases and naming conflicts |
| unison-src/transcripts/idempotent/help.md | Updated help documentation to describe the new moveTo and rename commands, removed rename as alias for move |
| unison-cli/unison-cli.cabal | Added new module entries for MoveTo and Rename handlers |
| unison-cli/src/Unison/CommandLine/OutputMessages.hs | Added pretty-printing functions for move results, rename results, and conflict messages |
| unison-cli/src/Unison/CommandLine/InputPatterns.hs | Defined input patterns for moveTo and rename commands with parameter validation |
| unison-cli/src/Unison/Codebase/Editor/Output.hs | Added new output types for MoveToResult, RenameResult, and MoveToConflicts |
| unison-cli/src/Unison/Codebase/Editor/Input.hs | Added new input types MoveToI and RenameI to represent the commands |
| unison-cli/src/Unison/Codebase/Editor/HandleInput/Rename.hs | New handler that changes only the final segment of a name by constructing a destination with the same parent path |
| unison-cli/src/Unison/Codebase/Editor/HandleInput/MoveTo.hs | New handler that moves multiple items into a destination namespace, detecting and reporting naming conflicts |
| unison-cli/src/Unison/Codebase/Editor/HandleInput.hs | Integrated the new command handlers and added input description formatting for both commands |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Overview
Resolves #4942
See move-to-and-rename.md for a demonstration.
Implementation approach and notes
How does it accomplish it, in broad strokes? i.e. How does it change the Haskell codebase?
Interesting/controversial decisions
Include anything that you thought twice about, debated, chose arbitrarily, etc.
What could have been done differently, but wasn't? And why?
Test coverage
Have you included tests (which could be a transcript) for this change, or is it somehow covered by existing tests?
Would you recommend improving the test coverage (either as part of this PR or as a separate issue) or do you think it’s adequate?
If you only tested by hand, because that's all that's practical to do for this change, mention that. Include screenshots.
Loose ends
Link to related issues that address things you didn't get to. Stuff you encountered on the way and decided not to include in this PR.
Final checklist