You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
just repos::hygiene (and repos::hygiene-prune) fail when invoked from a jj workspace or git worktree checkout because the recipe runs bookmark-pr-hygiene.sh with the justfile directory as CWD (~), not the directory the operator invoked just from.
The recent GH_CONFIG_DIR profile export fix (PR #116 / 75158bb) correctly unblocks command gh auth for subprocesses, but does not address this cwd problem.
Reproduction
From a jj workspace (no colocated .git), e.g. ~/dev/projects/tmuxr/work:
cd~/dev/projects/tmuxr/work
jj root # succeeds
just repos::hygiene
Actual:
not inside a jj or git repository
error: recipe `hygiene` failed on line 16 with exit code 1
Expected: audit runs against the checkout in the current working directory.
Direct script invocation from the same directory works (modulo separate gh API flakiness):
bookmark-pr-hygiene.sh auto-detects VCS mode via jj root / git rev-parse from current working directory. When just is invoked from a project-task workspace under ~/dev/projects/…, the recipe still runs in ~.
Proposed fix
Use just's invocation_directory() so hygiene runs where the operator stands:
When running the script directly from a jj workspace, back-to-back gh repo view + gh pr list calls sometimes fail with error connecting to api.github.com; a short delay or retry between calls succeeds. Worth considering retries or avoiding --search in bookmark-pr-hygiene.sh if this reproduces outside agent/sandbox environments.
Docs say worktrees/jj workspaces are supported (docs/repo-maintenance.md); the just recipe cwd mismatch blocks the documented just repos::hygiene entry point from those checkouts.
Summary
just repos::hygiene(andrepos::hygiene-prune) fail when invoked from a jj workspace or git worktree checkout because the recipe runsbookmark-pr-hygiene.shwith the justfile directory as CWD (~), not the directory the operator invokedjustfrom.The recent
GH_CONFIG_DIRprofile export fix (PR #116 /75158bb) correctly unblockscommand ghauth for subprocesses, but does not address this cwd problem.Reproduction
From a jj workspace (no colocated
.git), e.g.~/dev/projects/tmuxr/work:Actual:
Expected: audit runs against the checkout in the current working directory.
Direct script invocation from the same directory works (modulo separate gh API flakiness):
Root cause
repos.justresolves the script path fromjustfile_directory()but nevercds into the invocation directory before executing:bookmark-pr-hygiene.shauto-detects VCS mode viajj root/git rev-parsefrom current working directory. Whenjustis invoked from a project-task workspace under~/dev/projects/…, the recipe still runs in~.Proposed fix
Use just's
invocation_directory()so hygiene runs where the operator stands:Apply the same pattern to
hygiene-prune.Secondary follow-up (optional)
When running the script directly from a jj workspace, back-to-back
gh repo view+gh pr listcalls sometimes fail witherror connecting to api.github.com; a short delay or retry between calls succeeds. Worth considering retries or avoiding--searchinbookmark-pr-hygiene.shif this reproduces outside agent/sandbox environments.Context
aguil/workafter merging PR fix shell, vim, and git startup compatibility #9 (fix/workd-sidebar-lag).docs/repo-maintenance.md); the just recipe cwd mismatch blocks the documentedjust repos::hygieneentry point from those checkouts.