Skip to content

fix(update): only flag an update when the install is behind - #87

Open
cn0303 wants to merge 1 commit into
huggingface:mainfrom
cn0303:fix/update-check-only-when-behind
Open

fix(update): only flag an update when the install is behind#87
cn0303 wants to merge 1 commit into
huggingface:mainfrom
cn0303:fix/update-check-only-when-behind

Conversation

@cn0303

@cn0303 cn0303 commented Jul 25, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

The update notifier flagged "update available" whenever the repo HEAD differed
from the installed commit, in either direction. So an install that was ahead
of the default branch (a dev build) or on a branch that had diverged (a
force-push or rewritten history) still got nagged to update, and the in-place
--force reinstall the button offers would have discarded those local commits.

The cause

_compute_status() compared the installed commit to the repo HEAD and set
update_available = True for any difference:

compare = _github_json(f"/repos/{owner}/{repo}/compare/{current}...{latest}")
if isinstance(compare, dict):
    base.commits_behind = compare.get("ahead_by")
    base.compare_url = compare.get("html_url")
base.update_available = True   # <- true for ahead / behind / diverged alike

GitHub's compare(base=installed, head=latest) already classifies the
relationship in its status field (ahead, behind, diverged, identical),
but the code ignored it.

The fix

Gate on status == "ahead", the one case where the repo has strictly newer
commits the install can fast-forward to:

if isinstance(compare, dict):
    base.commits_behind = compare.get("ahead_by")
    base.compare_url = compare.get("html_url")
    base.update_available = compare.get("status") == "ahead"

behind (the install is ahead of the default branch) and diverged now stay
silent, as does an unavailable compare (for instance when the installed commit is
no longer in the repo), rather than guessing.

Before / after

Install relationship to default branch compare status Before After
Behind (normal, new commits upstream) ahead "update available" "update available" (unchanged)
Up to date identical silent silent (unchanged)
Ahead (dev build) behind "update available", 0 commits behind silent
Diverged (force-push / rewritten history) diverged "update available" silent
GitHub compare unreachable "update available" silent

Testing

Reproduced with unit tests that feed _github_json a canned compare response.
Three new tests (diverged, install-ahead, compare-unavailable) fail against the
current code and pass with the fix; the existing "update available" and
"up to date" cases still pass. pytest tests/test_update.py: 20 passed. ruff
check and ruff format green; pre-commit (mypy, bandit, typos) green.

The update notifier flagged "update available" whenever the repo HEAD differed
from the installed commit, in either direction. If the installed commit was
ahead of the default branch (a dev build) or the branch had diverged (a
force-push / rewritten history), it still nagged, and the in-place --force
reinstall it offers would have discarded those local commits.

GitHub's compare(base=installed, head=latest) already classifies the
relationship. Gate on status == "ahead", the one case where the repo has
strictly newer commits the install can fast-forward to. "behind" and
"diverged" now stay silent, and so does an unavailable compare (e.g. the
installed commit is no longer in the repo), rather than guessing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant