Add workspace repo import#23
Conversation
Why: - Cargo.lock still recorded workspace crate package versions as 0.1.0 after the 0.2.0 release work. - Running the current Rust test suite updates those entries automatically, so the lockfile was out of sync with the repo state. What: - refresh workspace crate version metadata in Cargo.lock from 0.1.0 to 0.2.0 Tests: - cargo test -p app -p api -p forge Risk: - low; no dependency graph change, only workspace package metadata refresh.
Why: - Forge can link a single project to a workdir, but it still lacks the batch import path needed for repo-heavy workflows. - Import has to live in the daemon so CLI and UI share the same scan, validation, and conflict handling behavior. What: - add project import request/response types - add daemon-side workspace scanning for nested git repositories - create new projects or link matching unlinked projects during import - return explicit skip reasons for already-linked or conflicting repos - expose the import endpoint through the API and cover it with regression tests Tests: - cargo test -p app -p api -p forge Risk: - medium; this touches project creation and path-linking flows, but it reuses the existing service validation path and is covered by service and API tests.
Why: - The new workspace import capability needs a first-class CLI entry point so repo-heavy users can onboard projects without using the UI. - Import should be invokable from any terminal, including the current working directory. What: - add orge project import [path] - default import root to the current working directory when no path is supplied - print created, linked, and skipped repo results from the daemon response - add a CLI regression test for workspace import Tests: - cargo test -p app -p api -p forge Risk: - low; this is a thin client wrapper over the new daemon import endpoint.
Why: - Workdir linking is present in the Projects screen, but batch repo import still required dropping to the CLI. - The Projects surface needs a visible import path and clear result feedback for created, linked, and skipped repos. What: - add frontend API/types for project import - add an Import Workspace action in the Projects screen - add a dialog for selecting a workspace root and triggering import through the daemon API - render import results for created, linked, and skipped repositories Tests: - npm run build --prefix frontend Risk: - low; the UI uses the new import endpoint and existing global query invalidation.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d09fe1d4b0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| .find(|project| { | ||
| project.workdir_path.is_none() | ||
| && (project.slug == repo_slug || project.name.eq_ignore_ascii_case(repo_name)) |
There was a problem hiding this comment.
If a workspace contains a repo whose name matches an archived placeholder project, find_unlinked_project_match will still return that archived row because it only checks workdir_path.is_none() plus slug/name equality. import_projects then links the repo to the archived project instead of creating a visible active one, but the normal projects list still hides archived records (crates/api/src/lib.rs:105-112, used by frontend/src/App.tsx:339-341). In that case the import reports success, yet the repo never appears in the main Projects screen.
Useful? React with 👍 / 👎.
1 participant
Summary
forge project importTesting
Closes #22