What this fixes

Repository.push() hands the URL it reads back from the checkout straight to git push:

# modelscope/hub/repository.py:141
url = self.git_wrapper.get_repo_remote_url(self.model_dir)
...
self.git_wrapper.push(
    repo_dir=self.model_dir,
    git_token=self.git_token,     # the caller's fresh token
    url=url,                      # ... but this URL still carries the old one
    ...
)

A URL obtained from an existing checkout still contains the token that was embedded when the repository was cloned. config_git_token returns early when the remote already contains //oauth2, and _inject_token likewise passes an already-tokened URL through unchanged — so self.git_token is silently discarded and git authenticates with the stale token.

Its twin does not have this problem. DatasetRepository.push() strips first, and so does _clone_if_needed:

# :253-255  (DatasetRepository.push)
remote_url = self.git_wrapper.get_repo_remote_url(self.repo_work_dir)
remote_url = self.git_wrapper.remove_token_from_url(remote_url)

# :45-46  (_clone_if_needed)
existing = git_wrapper.get_repo_remote_url(repo_dir)
existing = git_wrapper.remove_token_from_url(existing)

Repository.push() is the only one of the three call sites that omits it.

Consequence

After a token rotation, a push from an existing checkout fails authentication even though the caller passed a valid git_token, and there is no SDK-level recovery — the stale secret stays in .git/config. DatasetRepository.push() with the same token on the same machine works, which makes it look like a permissions problem rather than a stale-credential one. save_pretrained(push_to_hub=True) (patcher.py:487), cli/modelcard.py:141 and push_to_hub.py:66 all route through Repository.push().

Reproduction

Both push methods were executed from the real source (function AST extracted and bound to a stub object, with a recorder git_wrapper; only the network-facing wrapper is stubbed). The remote URL the wrapper returns is tokened, exactly as an existing clone would be, and both callers pass git_token="NEW_TOKEN". The recorder prints the URL that would reach git push:

BEFORE (upstream main)
  Repository          git_token=NEW_TOKEN   url userinfo = OLD_SECRET    <-- the stale token is what git uses
  DatasetRepository   git_token=NEW_TOKEN   url userinfo = (no embedded token)   ok

AFTER (this change)
  Repository          git_token=NEW_TOKEN   url userinfo = (no embedded token)   ok
  DatasetRepository   git_token=NEW_TOKEN   url userinfo = (no embedded token)   ok

DatasetRepository is unchanged in both runs; only Repository changes.

Change

One line:

         url = self.git_wrapper.get_repo_remote_url(self.model_dir)
+        url = self.git_wrapper.remove_token_from_url(url)

Validation

• python -m py_compile modelscope/hub/repository.py → OK
• flake8 --max-line-length=120 modelscope/hub/repository.py → exit 0
• yapf --diff (the hook the repo pins at v0.30.0) → no diff
• The reproduction above, before and after.

Not verified: a real push against the Hub — I have no credentials for it. The claim is limited to what the method passes to the git wrapper, which is where the divergence is. I also did not run the repository's own test suite (it is not installed in this environment).

Notes for reviewers

• Repository.push() carries a DeprecationWarning pointing at HubApi().upload_folder. I fixed it rather than leaving it, because the documented successor does not automatically cover the callers that still route through it (save_pretrained(push_to_hub=True), cli/modelcard.py, push_to_hub.py) and because the fix is what makes it agree with its twin. Happy to close this in favour of a different approach if you would rather deprecate harder.
• The missing strip is long-standing rather than a recent regression, so there is no issue to reference.

Competition

No competing item. gh searches for remove_token_from_url, Repository.push and git_token return no matching issue or PR, and none of the six currently open PRs touches modelscope/hub/repository.py (the merged #1592 touched only hub/api.py).