Skip to content

fix(app): raise the window a repository already has - #47

Merged
LeadcodeDev merged 1 commit into
mainfrom
fix/focus-open-repo
Aug 22, 2026
Merged

fix(app): raise the window a repository already has#47
LeadcodeDev merged 1 commit into
mainfrom
fix/focus-open-repo

Conversation

@LeadcodeDev

Copy link
Copy Markdown
Collaborator

Closes #45.

gitr <path> for a repository already open added a second window for it. The handoff was
never the problem — it routes the path correctly — and ProjectList::add_or_activate
dedupes the persisted list, which has nothing to do with what is on screen.

The key is already canonical

A HashMap<PathBuf, WindowHandle<Root>>, consulted before opening. Both sides agree on the
key without any new normalisation: resolve_repository_root canonicalises before the path
goes into the socket, which is what makes /tmp/x and /private/tmp/x one entry rather
than two. The transcript below shows that happening.

No window-close hook

The issue's sketch says "populated when open_window succeeds and cleared when that window
closes". The second half is not needed and is the riskier half.

WindowHandle::update returns Err once its window is gone, so raising is the liveness
check: a closed window's entry is detected and dropped the next time that repository is
asked for, and the request that found it stale is the one that opens the replacement.
Pruning eagerly would buy back one map entry per repository opened in this process. That
leak is worth less than the code that plugs it — and a close hook that missed a case would
fail in the worse direction, leaving an entry that outlives its window and stops the
repository ever opening again.

Verified on the real handoff

No UI automation involved — these are four command-line invocations against one running
instance, with the decision logged at each request:

gitr <this repo>     → raised existing window for /Users/…/gitr
gitr /tmp/other-repo → opening new window for   /private/tmp/other-repo
gitr <this repo>     → raised existing window for /Users/…/gitr

The /private/tmp line is the canonicalisation doing its job.

Not exercised: the stale-handle path. Closing a window needs the UI, which this cannot
drive. What needs a human: close a repository's window, then run gitr for it again — it
should open fresh rather than do nothing.

cargo test --workspace green; cargo clippy --workspace --all-targets -- -D warnings;
cargo fmt --all --check.

@LeadcodeDev LeadcodeDev added the bug Something isn't working label Aug 22, 2026
@LeadcodeDev LeadcodeDev self-assigned this Aug 22, 2026
…ond one

The handoff routed the second invocation's path to the live process correctly and
that process opened another window for it every time. `add_or_activate` dedupes
the persisted project list, which has nothing to do with what is on screen.

A map from canonical root to `WindowHandle`, consulted before opening. Both sides
already agree on the key: `resolve_repository_root` canonicalises before the path
goes into the socket, which is what makes `/tmp/x` and `/private/tmp/x` one entry
rather than two.

No window-close hook. `WindowHandle::update` fails once its window is gone, so
raising doubles as the liveness check and a closed window's entry is dropped the
next time that repository is asked for. Watching for closes to prune eagerly
would buy back one map entry per repository opened in this process — a leak worth
less than the code that plugs it, and a close hook that missed a case would be
the worse failure: an entry that outlives its window and stops the repository
ever opening again.

Verified by driving the real handoff: same repository raises, a different one
opens, the first raises again. The stale-handle path is not exercised, since
closing a window from the command line is not something this can do.
@LeadcodeDev
LeadcodeDev merged commit 753bf89 into main Aug 22, 2026
3 checks passed
@LeadcodeDev
LeadcodeDev deleted the fix/focus-open-repo branch August 22, 2026 09:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reopening an already-open repo spawns a duplicate window instead of focusing it

1 participant