fix(desktop,cli): stop rendering the unknown update count as "1 change included" - #83381
Closed
Dolverin wants to merge 2 commits into
Closed
fix(desktop,cli): stop rendering the unknown update count as "1 change included"#83381Dolverin wants to merge 2 commits into
Dolverin wants to merge 2 commits into
Conversation
…ded' on shallow clones On an installer checkout (clone --depth 1) with no merge-base against the freshly fetched origin tip, resolveBehindCount returned the sentinel 1 and every surface rendered it as a literal count: 'A new update is ready (1 change included).' — even when the true distance was far larger (observed: 90 commits). The sentinel was meant to mean 'update available, exact count unknown', but nothing downstream distinguished it from a real one. - update-count.ts: return null (unknown) instead of the numeric sentinel - main.ts: flag updateAvailable explicitly and still serve the (capped) commit log so 'See what's new' stays useful in the unknown case - updates.ts: toast fires for behind:null + updateAvailable, with count-free copy instead of being swallowed by the <= 0 guard - about-settings.tsx: status line and action buttons key off updateAvailable; unknown size renders the new count-free string - i18n: updateReadyUnknown / updateReadyMessageUnknown in all 5 locales Refs NousResearch#51922 (the shallow-clone special case this UI now renders honestly). Tests: vitest electron 10/10, ui 44/44 (3 FAIL-BEFORE reds turned green), tsc typecheck clean, eslint clean on all touched files.
The official-SSH branch of _check_via_local_git collapsed UPDATE_AVAILABLE_NO_COUNT (-1) to a literal 1, so the startup banner and 'hermes version' printed "1 commit behind" for shallow installer clones — the desktop UI's "1 change included" lie, second source. Pass the sentinel through and teach cmd_version the generic 'Update available' line. The REST payload (-1) already maps to update_available=True, which the fixed desktop now renders count-free.
Contributor
|
Merged via PR #86257 — your commit was cherry-picked onto current main with your authorship preserved in git log (bf10349). Thanks! Your null-sentinel + updateAvailable plumbing (store, toast, About settings, all locales, CLI renderer) is the honesty backbone of the class fix. We combined it with #64469's shallow-always-skip/ancestor-proof design and added exact-count recovery via the GitHub compare API on top. |
This was referenced Aug 14, 2026
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
2 participants
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.
Problem
Windows installer checkouts are shallow (
clone --depth 1), and passive update checks against the official SSH origin deliberately use presence-only HTTPSls-remoteso a FIDO2/passkey key is never touched (#51922 documented the fallout of trustingrev-listthere). In that state the exact behind-count is unknowable — but the sentinel value for "unknown" was a literal1, and every surface rendered it as a real number:hermes version: "1 commit behind"The code comments already stated the intent ("show a generic update available"), but nothing downstream distinguished the sentinel from a real count.
Fix
Pass "unknown" through honestly instead of faking precision:
update-count.tsreturnsnullfor the unknowable case; the main process setsupdateAvailableexplicitly and still serves the (capped) commit log, so "See what's new" keeps workingupdateAvailableand render new count-free strings (updateReadyUnknown/updateReadyMessageUnknown, all 5 locales) when no exact count exists_check_via_local_gitnow returnsUPDATE_AVAILABLE_NO_COUNT(-1) unchanged — consistent with the existing shallow path — andhermes versionprints a generic "Update available" line instead of "1 commit behind"Tests
New FAIL-BEFORE coverage: desktop sentinel returns
null(was1), store toast fires with count-free copy for unknown counts (was swallowed by the<= 0guard), CLI SSH path keeps-1(was1),hermes versionshows the generic line.vitest --project electron: 10/10vitest --project ui: 44/44pytest tests/hermes_cli/test_update_check.py: 5/5tsctypecheck clean (3 configs); eslint clean on all touched files