Repository navigation
Replies: 2 comments
|
The hierarchy is right. One thing I would make impossible to hand-wave is read scope versus write scope. A single root shell inside a multi-repo workspace quietly turns every context repo into writable authority. Let the task carry a per-repo capability map and revision pin, then build the aggregate review from that manifest rather than from whatever repos happen to be dirty. |
|
Following the redirect from #4962, which was closed because feature requests belong in Discussions, here is a tested cross-project use case. For a GNOME 51 migration across five independent GNOME Shell extension repositories, I successfully tested this orchestration in Paseo with Codex:
From a dedicated non-Git This fits the task-centric model discussed here: separate repositories and workers, grouped around one logical migration task. A reusable way to select projects, group workers, and review their results together would make the existing capability easier to use; the tested setup did not require a shared workspace root or matching branch names. Project discovery was the concrete gap: the agent's workspace listing exposed only |
Uh oh!
There was an error while loading. Please reload this page.
Problem
Paseo currently appears to model a workspace around a single Git repository/worktree.
That is a reasonable assumption for traditional manual development, where a developer usually opens one repository and works within that repository's branch, diff, PR, and review context.
It is a poor abstraction for agentic development.
With coding agents, the natural unit of work is often the task or development environment, not the Git repository. A logically single task may require coordinated access to multiple related repositories, for example:
A directory such as:
may therefore represent one coherent development workspace even though its contents have different Git repositories, ownership, visibility, and lifecycle.
Requiring each repository to become a separate Paseo workspace breaks that logical relationship.
Repository boundaries are not context boundaries
This distinction is particularly important for agents.
An agent may not need to modify
shared-library, but it may absolutely need to inspect and reason through it in order to correctly integrateservice-a.Likewise, architecture documents, protocol specifications, ADRs, internal notes, deployment configuration, and test repositories may all be part of the context required to make a correct change without naturally belonging in the same Git repository.
Some of those repositories may intentionally have different external visibility:
Combining them into one repository simply to satisfy the development tool would be the wrong architectural answer.
The workspace should model the engineering environment, not force the engineering environment to match a Git layout.
Why this matters more with agents
Agents do not have the same working constraints as a human developer.
A human tends to serialise work around repository boundaries because switching context is expensive. Agents can inspect, modify, test, and reason across several repositories as part of one task.
Artificially splitting those repositories into separate workspaces creates several problems.
1. It deprives the agent of necessary context
The most serious problem is not merely inconvenience. It can reduce the quality of the agent's reasoning.
A change in
service-amay depend on:shared-libraryThe agent may only be editing one repository, but it still needs access to the wider environment to understand what a correct implementation looks like.
Constraining the workspace to the repository being modified encourages an artificial equivalence:
That is frequently false.
For agentic development, richer read context is often more important than write scope.
2. It damages task-level reasoning
The agent loses the natural enclosing context of the task.
A change in
service-amay only make sense in combination with a change inshared-library. If those are represented as unrelated workspaces, the system encourages reasoning about each repository independently when the actual engineering problem spans both.Repository boundaries are source-control boundaries. They are not necessarily reasoning boundaries.
3. It forces humans to reconstruct context
The human reviewer should be able to ask:
The answer may span several repositories or worktrees.
If each one is isolated into a separate workspace, the reviewer has to manually reconstruct the task by switching between workspaces, remembering which branches belong together, comparing separate diffs, checking separate PR states, and correlating failures.
That is exactly the coordination overhead an agentic development environment should be removing.
4. It produces poor review dynamics
Review should be task-centric first and repository-centric second.
For a multi-repository task, the useful review surface is something like:
The Git repository still remains the correct transactional unit for commits and PRs, but it should not have to be the top-level UI or workspace boundary.
5. It interferes with fluid worktree development
The single-repository assumption is particularly awkward when worktrees are used heavily.
A worktree is technically linked to the same underlying Git repository, but operationally it presents another independent working tree with its own branch, filesystem location, dirty state, and unit of work.
In agentic development, that is exactly why worktrees are useful.
A larger task might look like:
Here,
task-authis the meaningful unit of work. It may involve a worktree fromservice-a, another fromservice-b, and read access toshared-libraryandarchitecture.Treating each worktree location as effectively requiring its own isolated Paseo workspace reverses the useful hierarchy.
The worktree should be a resource belonging to a task, not the boundary of the entire development environment.
Otherwise worktree-based parallelism becomes UI fragmentation.
6. It encourages agents to work with incomplete context
A particularly undesirable consequence is that users may create smaller repository-specific workspaces merely to satisfy the tool.
That means agents are then started with less context than the real task requires.
For agentic development, deliberately reducing available context in order to fit a UI abstraction is backwards. The environment should represent the real engineering context and allow the agent to decide which parts are relevant.
Write permissions and reasoning context also do not need to be identical. An agent can have a narrow set of repositories/worktrees it is expected to modify while retaining read access to a much larger environment.
7. It scales badly with parallel agent work
Parallel development makes this worse.
A user may have:
Those relationships are task-shaped, not repository-shaped.
Making every repository or active worktree its own Paseo workspace produces a growing matrix of workspaces that the human must mentally map back onto tasks.
That is the inverse of what an agent orchestration environment should provide.
Suggested model
A more useful hierarchy for agentic development would be:
The important separation is:
workspace = context
task = unit of work
repository = source-control boundary
worktree = isolated working state within a repository
PR = review/merge boundary for a repository
These concepts should not be collapsed into one object.
A workspace could discover or explicitly register multiple Git repositories beneath or outside its root.
Git operations would still be scoped to an individual repository, but Paseo could aggregate their state at the workspace and task levels.
For example:
Selecting the task could provide an aggregate review view, while selecting a repository or worktree would provide the existing repository-specific Git view.
Important distinction
This does not require treating multiple repositories as one Git repository.
Each repository should retain its own:
Nor does every repository present in a workspace need to be writable.
The requested change is that Git repository and worktree boundaries should not also dictate Paseo's context and workspace boundaries.
That distinction becomes increasingly important as development moves from one human operating one checkout toward multiple agents working concurrently across related codebases.
Expected outcome
A Paseo workspace should be able to represent a logically coherent development environment containing multiple independent Git repositories and multiple worktrees.
An agent should be able to:
Git and review functionality should then operate at both levels:
That model is much better aligned with agentic development than treating a Git checkout as the fundamental boundary of context, work, and review.
All reactions