Files
hermes-agent/hermes_cli
gkd2323c 294071bf08 fix(banner): stop fabricating '1 commit behind' on SSH-official remotes
The SSH-official-remote path in _check_via_local_git was hard-coded to
return 1 when _check_via_rev reported UPDATE_AVAILABLE_NO_COUNT, so
'hermes --version' and the CLI banner surfaced a stable but false
'Update available: 1 commit behind — run hermes update' message. The
count never grew: whether upstream was 1 commit or 100 commits ahead,
the banner always said '1 commit behind'.

Root cause: an ls-remote probe against the upstream URL can only tell
us tip SHAs, not a real commit count. Returning the sentinel
UPDATE_AVAILABLE_NO_COUNT (-1) already means 'update exists, count
unknown' — the exact right shape for this path.

The dashboard/desktop UI does not depend on the fabricated 1:

- The REST /api/hermes/update/check endpoint
  (hermes_cli/web_server.py::check_hermes_update) treats any nonzero
  behind as update_available=true, and its docstring explicitly
  documents -1 as a legitimate value.
- The desktop store (apps/desktop/src/store/updates.ts::mapBackendCheck)
  clamps behind<=0 to 0 and reads updateAvailable as a separate boolean
  field.

So restoring the sentinel is a strict improvement: CLI banner and
hermes --version now say 'Update available' honestly instead of
inventing a count, and every REST/desktop consumer keeps working.

Changes:
- hermes_cli/banner.py: drop the 'return 1' override in the SSH branch;
  propagate the sentinel unchanged.
- hermes_cli/main.py::_print_version_info: render the sentinel as
  'Update available — run <cmd>' (without a count).
- tests/hermes_cli/test_update_check.py: update the SSH-official test
  to assert on the sentinel; add 3 new tests covering the CLI
  renderer's -1 / >0 / 0 branches.
2026-08-14 13:09:44 -07:00
..
2026-08-13 11:52:47 -07:00
…
2026-08-10 12:43:46 -07:00
…