git-xet: Add version 0.2.1

[haussmann]

git-xet: Add version v0.2.0

• Can't use traditional Github checkver, because the repository contains releases for multiple different topics and no latest tag

Closes: #7516

• Use conventional PR title: <manifest-name[@version]|chore>: <general summary of the pull request>
• I have read the Contributing Guide

Summary by CodeRabbit

• New Features
  • Added support for the Xet protocol as a Git LFS custom transfer agent.

[z-Fng]

• Tests necessary whether git xet install is required

I think adding a note to guide users is sufficient, since git xet install can be applied to different scopes.

PS> git xet install --help
Perform the following action to register Git-Xet:

Set up the "xet" transfer agent under the name "lfs.customtransfer.xet" in
global Git config with the below values
    path = git-xet
    args = transfer
    concurrent = <according to value from option "--concurrency" (default true)>

If "--concurrency" is specified, set "lfs.concurrenttransfers" in the global
Git config to this number.

Usage: git-xet.exe install [OPTIONS]

Options:
      --system
          Set the "xet" transfer agent and the number of concurrent LFS transfers in the system git config, e.g. /etc/gitconfig instead of the global git config (~/.gitconfig)

      --local
          Set the "xet" transfer agent and the number of concurrent LFS transfers in the local repository's git config, instead of the global git config (~/.gitconfig)

      --path <PATH>
          The path to the repository. This argument only applies when "--local" is specified

      --concurrency <CONCURRENCY>
          The number of concurrent LFS uploads/downloads. Default 8

  -h, --help
          Print help (see a summary with '-h')

  -V, --version
          Print version

[haussmann]

I think adding a note to guide users is sufficient [...]

Thank you! That makes sense to me. I added the following note:
Follow instructions in git xet install --help after installation.

[haussmann]

/verify

@coderabbitai full review

[github-actions]

All changes look good.

Wait for review from human collaborators.

git-xet

• Lint
• Description
• License
• Hashes
• Checkver
• Autoupdate

Check the full log for details.

[coderabbitai]

@haussmann: I'll perform a full review of the PR now.

✅ Actions performed

Full review triggered.

[coderabbitai]

📝 Walkthrough

Walkthrough

A new manifest file for git-xet (Xet protocol Git extension) has been added to the bucket directory with version 0.2.1, including metadata, architecture-specific download details, binary information, and autoupdate configuration.

Changes

Cohort / File(s)	Summary
Git-xet Manifest bucket/git-xet.json	Added new package manifest declaring git-xet v0.2.1 with description, homepage, license, prerequisites, 64-bit download URL with sha256 hash verification, binary name (git-xet.exe), checkver regex pattern, and autoupdate templating configuration.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

Suggested reviewers

• z-Fng

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'git-xet: Add version 0.2.1' accurately summarizes the main change—adding a new manifest file for git-xet with version 0.2.1.
Linked Issues check	✅ Passed	The PR substantially meets all coding-related objectives from issue #7516: the manifest confirms git-xet as a non-GUI tool, verifies it has sufficient popularity (393 stars, 51 forks), uses a standard install via version-specific download URL, includes required metadata (name, description, homepage), and provides the latest stable version.
Out of Scope Changes check	✅ Passed	The PR is tightly scoped; it adds only the git-xet.json manifest file directly supporting issue #7516 requirements with no extraneous or unrelated modifications.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description check	✅ Passed	The PR description addresses the issue with checkver limitations and includes required checklist items, but lacks detail about the manifest's functionality and purpose.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@bucket/git-xet.json`:
- Line 4: Replace the broken homepage URL value for the "homepage" JSON key
(currently "https://huggingface.co/docs/hub/xet/") with the working URL
"https://huggingface.co/docs/hub/xet/index" in the JSON object (update the value
for the homepage property in the same entry).

---

ℹ️ Review info

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d03dda8 and be348a3.

📒 Files selected for processing (1)

• bucket/git-xet.json

[SorYoshino]

I believe the current checkver field should be revised, as it has several issues:

• Most manifests that use the GitHub API reference the repository ID rather than the repository name.
• By default, per_page is set to 30, which is sufficient for most cases. For checkver to fail under this setting, 30 consecutive releases would need to exclude git-xet, which is highly unlikely. Setting per_page to 100 is therefore unnecessary. If additional precaution is desired, I believe 45 would be sufficient.
• A pre-release version may be detected. Although this would not cause the manifest to update to a pre-release version, it would lead to a failure during update checking.

One possible solution are provided below:

{
    "checkver": {
        "url": "https://api.github.com/repositories/855423236/releases?per_page=45",
        "jsonpath": "$[?(@.prerelease == false)].assets[?(@.name =~ /git-xet/i)].browser_download_url",
        "regex": "(?i)download/git-xet-v([\\d.]+)/git-xet"
    }
}

[z-Fng]

• Most manifests that use the GitHub API reference the repository ID rather than the repository name.

I'd suggest using repository names instead of repo IDs in the GitHub API, as the API now properly supports redirects. To complement this, we're going to introduce an automation to automatically correct and sync repo names in our buckets.

• By default, per_page is set to 30, which is sufficient for most cases. For checkver to fail under this setting, 30 consecutive releases would need to exclude git-xet, which is highly unlikely. Setting per_page to 100 is therefore unnecessary. If additional precaution is desired, I believe 45 would be sufficient.
• A pre-release version may be detected. Although this would not cause the manifest to update to a pre-release version, it would lead to a failure during update checking.

It should be fine for now. But if you'd like to make it more robust, feel free to submit a PR.

[SorYoshino]

I'd suggest using repository names instead of repo IDs in the GitHub API, as the API now properly supports redirects. To complement this, we're going to introduce an automation to automatically correct and sync repo names in our buckets.

Thank you for your explanation.

It should be fine for now. But if you'd like to make it more robust, feel free to submit a PR.

I will submit a PR later to refine it.