Conversation
Codex flagged (PR #14) that PrereqBanner's "Commit-time editing is disabled" was cosmetic: the check lived in the banner's local state, so ApplyPanel still enabled "Rewrite history" whenever dates were queued — letting the user confirm the destructive op (and create a backup) before it inevitably failed for lack of a working git-filter-repo. Lift the probe into a shared singleton (prerequisites.svelte.ts) so the banner and the editing controls read the SAME result. ApplyPanel now disables the Rewrite button (with an explanatory tooltip) when canEditHistory is false, and rewrite() bails early as defense in depth. Unknown/non-Tauri → treated as available so nothing is blocked prematurely. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Website badge → git-it.app (NERV orange), license badge → the CC BY-NC-SA 4.0 LICENSE file, alongside the existing CI/release/downloads/platform/tauri badges. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… the gate Codex flagged (PR #16) that load() cached the resolved promise forever, so after a successful probe with a negative result there was no way to re-run it — if the user installed the Command Line Tools (or otherwise fixed a prereq) while Git It stayed open, the banner and the disabled Rewrite button persisted until restart. Add prerequisites.refresh() (forces a fresh probe) and call it from PrereqBanner on window `focus` while a prerequisite is still missing — reliably catching the return-to-app moment after the async `xcode-select --install` finishes. Stops re-probing once everything's present. load() stays deduped. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
fix(prereq): gate history rewrite on filter-repo probe + README badges
…is gone When a remote branch is deleted elsewhere (e.g. a merged PR whose branch was auto-deleted), the local refs/remotes/<remote>/<branch> tracking ref lingers until a fetch --prune. "Delete remote branch" then ran `git push --delete`, which git rejects with "remote ref does not exist" — so the phantom never cleared and every retry re-failed, with no useful feedback. delete_remote_branch now treats that specific case as success: it prunes the stale tracking ref locally (show-ref --verify, then update-ref -d) and returns Ok. Every other failure (auth, network, protected branch) still surfaces. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Failed nav/branch ops only set a muted status-bar line that was easy to miss and got overwritten by the next refresh, and the graph was not repainted on failure — so a partial success (local branch deleted, remote delete failed) looked like nothing happened. The run() wrapper now repaints the graph even on failure and surfaces the full error in a new message-only "alert" dialog, so a destructive op that fails is impossible to miss. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The spin animation was applied to the 30x30 bordered .refresh button, so transform: rotate() spun the border and background too. Wrap the glyph in an inline-block span and rotate that instead; the button box stays put. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
GitHub computes /stats/commit_activity lazily (HTTP 202 on a cold cache), so the first Insights load can throw a transient error. The old retry loop only handled the `computing` return value, so a thrown error hard-errored the panel until the user switched tabs and back (which forced a re-fetch — the reported symptom). Add fetchActivityWithRetry: retries through both `computing:true` and thrown transient errors with backoff, aborts early on permanent errors (NotFound/auth), and resolves to the soft "computing" marker if stats aren't ready in time. The retry policy is a pure, injected helper with unit tests. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… edits Code review caught that reloadGraph() in the run() failure path resets graphCommits via setGraphCommits(), which clears newDates (queued commit-time edits), selected, and currentSha. That silently discarded the user's queued edits and selection on ANY failed op — including non-mutating ones (rejected checkout, branch-already-exists, fetch error) that cannot have partially applied. Swap it for the non-destructive refreshRefs(): the sidebar still updates for a genuine partial success (local branch deleted, remote delete failed), but graphCommits and the queued edits are left intact. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…h locales Code review caught that delete_remote_branch matched git's English "remote ref does not exist" stderr to detect an already-deleted remote branch. Under a non-English git locale that message is translated, so the self-heal was skipped and the delete returned an error without pruning the stale tracking ref. Pin LC_ALL=C on the push --delete command so the diagnostic is always git's stable English text (Command::env overrides the child's locale regardless of the user's LANG/LC_*). Behavior is otherwise unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ation Follow-up to PR #17, which pinned LC_ALL=C on the branch-delete self-heal so its stderr match survived non-English git locales. Two more sites classify git's English stderr and would silently misfire under a translated locale: - looks_like_auth_failure (HTTPS auth-failure detection) — fed by every credentialed push/pull, all of which run through stream(). Pin LC_ALL=C there once so the combined output is stable English for all of them (including the credentialed retry, which also streams through it). - fast_forward_branch's non-fast-forward / [rejected] detection — pin LC_ALL=C on its fetch command. Scoped to these network commands rather than a global git_ops::run pin, which would force C-locale collation/formatting/messages onto every local git command whose output the app parses or displays. Command::env overrides the child's locale regardless of the user's environment; behavior is otherwise unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pin LC_ALL=C for auth and non-fast-forward error detection (locale robustness)
…ights Fix silent branch-delete, GitHub refresh-button spin, and Insights first-load
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: afeb243566
ℹ️ 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".
Code review (PR #19) caught that a transient prerequisite-probe failure wedged the shared singleton: probe()'s catch reset `check` to null but left `loading` holding the resolved promise, so load() no-op'd for the rest of the session — canEditHistory stayed true (history editing wrongly enabled) and the banner stayed hidden, with no retry path. - prerequisites.svelte.ts: reset `loading = null` in the catch so a later load()/refresh() actually re-probes. - PrereqBanner.svelte: re-probe on window focus when the probe hasn't succeeded (check === null), not only when a prerequisite is known-missing. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Codex (PR #20 review) noted the first fix still left the destructive rewrite reachable: canEditHistory returned true whenever `check` was null, which includes a FAILED probe — so between a transient failure and a successful retry, "Rewrite history" ran on unverified prerequisites with no warning. Track the failure separately: a new `probeFailed` flag distinguishes "probe rejected" from "not probed yet". canEditHistory now allows only when a probe succeeded or hasn't run yet (optimistic pre-first-probe / non-Tauri), and stays DISABLED once a probe has failed until a later probe succeeds. Guard the probe with isTauri so the browser preview stays "unknown", not "failed". Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Codex (PR #20 review) flagged that isRetryableActivityError retried a RateLimited error, so fetchActivityWithRetry hit the same endpoint five times over ~6s — a rate limit won't clear inside that fixed backoff, and re-hitting it prolongs the throttle. Narrow the predicate to the transient cold-cache case only: retry `Other`/parse errors and non-GithubError blips; do NOT retry RateLimited, Forbidden, or the permanent kinds. Update the unit tests accordingly. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…e editing Codex (PR #20 re-review) flagged a race: refresh() (window-focus) can start a probe while another is still in flight, and both write check/probeFailed on completion. A newer success followed by an older failure completing late would clobber the good result and wrongly re-disable history editing until the next focus cycle. Add a monotonic probeSeq: each probe captures its id and commits its result only if it is still the latest, so superseded/out-of-order completions are dropped. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Codex (PR #20 re-review) flagged that a still-pending initial probe left canEditHistory true (check null), so a slow probe let "Rewrite history" run before git/python3/filter-repo were verified — the probeFailed flag only covered the FAILED case, not the pending one. Make canEditHistory optimistic only in non-Tauri (browser preview): in the desktop app any non-success check (pending, failed, or unprobed) keeps editing DISABLED until a successful probe confirms availability. This subsumes the probeFailed flag, which is removed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
fix(ui): retry the prerequisite probe after a transient failure
feat: add worktree visibility and safe deletion
…ry-creation Improve updates, worktree management, and repository creation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Promotes
next→main, cutting the next stable release (post-v0.2.0). Three PRs have landed onnextsince the launch, all with green CI and Codex review:delete_remote_branchnow self-heals a stale remote-tracking ref when the remote branch was already deleted elsewhere (prunes locally instead of erroring). Failed git ops surface an error dialog and refresh the view (non-destructively, preserving queued edits). The GitHub refresh button spins only its glyph, not the whole button. GitHub Insights commit-activity retries through transient cold-cache (HTTP 202) errors instead of hard-erroring until a tab-switch.LC_ALL=Con the git commands whose stderr is classified (HTTPS auth-failure detection viastream(), and non-fast-forward detection), so those checks survive a non-English git locale.On merge: use a merge-commit with no skip-build — that cuts the stable release (
release.yml) and deploys the site (deploy-pages.yml).nextis the permanent integration branch (do not delete it).🤖 Generated with Claude Code