15011cb230
This PR makes two significant, breaking API redesign:
1. Auth tokens move from session-level (shared by all operations) to
per-operation level (per `UploadCommit`, `FileDownloadGroup`, and
`DownloadStreamGroup`). This enables uploads and downloads from the same
session to carry different access-level tokens — a sensible design for
HF's write-vs-read token split.
2. Instead of letting users provide a callback to refresh tokens, this
new API now let users provide a token refresh URL and access credential
in an HTTP header map.
### Why
1. CAS JWT have short life, but `XetSession` is intended to be held long
time -- thus it makes more sense to configure CAS auth on the operation
level (`UploadCommit` or `FileDownloadGroup` or `DownloadStreamGroup`)
and it will be discarded once the operation is done.
2. For different access level (write vs. read) and different operation
target (repo and commit), CAS JWT token will be different and the token
refresh URL will be different. `UploadCommit` and `FileDownloadGroup`
and `DownloadStreamGroup` they each also function as a single auth
group.
3. Providing an URL is considered easier than writing a callback, and is
more safe when crossing the GIL Python - Rust boundary.
Examples:
```
// Upload token (write access)
let mut upload_headers = HeaderMap::new();
upload_headers.insert("Authorization", "Bearer hub-write-token".parse().unwrap());
let commit = session
.new_upload_commit()?
.with_token_info("CAS_WRITE_JWT", 900)
.with_token_refresh_url("https://huggingface.co/api/repos/token/write", upload_headers)
.build_blocking()?;
```
```
// File download token (read access)
let mut dl_headers = HeaderMap::new();
dl_headers.insert("Authorization", "Bearer hub-read-token".parse().unwrap());
let group = session
.new_file_download_group()?
.with_token_info("CAS_READ_JWT", 900)
.with_token_refresh_url("https://huggingface.co/api/repos/token/read", dl_headers)
.build_blocking()?;
```
Secondary changes include:
- `DirectRefreshRouteTokenRefresher` consolidated into
`xet_client::cas_client::auth`.
- HTTP client module moved from `cas_client` to `xet_client::common` for
shared use between `xet_client::cas_client` and
`xet_client::hub_client`.
- New `DownloadStreamGroup` type (streaming downloads moved off
`XetSession`).
- Fix Session ID type regression: this was fixed once in
https://github.com/huggingface/xet-core/pull/738 but regressed again,
seems AI agents don't learn.
- HTTP client cache key now incorporates custom headers
Git-Xet is a Git LFS custom transfer agent that implements upload and download of files using the Xet protocol. Install git-xet, follow your regular workflow to git lfs track ... & git add ... & git commit ... & git push, and your files are uploaded to Hugging Face repos using the Xet protocol. Enjoy the dedupe!
Installation
Prerequisite
Make sure you have git and git-lfs installed and configured correctly.
macOS or Linux (amd64 or aarch64)
To install using Homebrew:
brew install git-xet
git xet install
Or, using an installation script, run the following in your terminal (requires curl and unzip):
curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/huggingface/xet-core/refs/heads/main/git_xet/install.sh | sh
To verify the installation, run:
git xet --version
Windows (amd64)
Using winget:
winget install git-xet
Using an installer:
- Download
git-xet-windows-installer-x86_64.zip(available here) and unzip. - Run the
msiinstaller file and follow the prompts.
Manual installation:
- Download
git-xet-windows-x86_64.zip(available here) and unzip. - Place the extracted
git-xet.exeunder aPATHdirectory. - Run
git-xet installin a terminal.
To verify the installation, run:
git xet --version
Uninstall
macOS or Linux
Using Homebrew:
git xet uninstall
brew uninstall git-xet
If you used the installation script (for MacOS or Linux), run the following in your terminal:
git xet uninstall
sudo rm $(which git-xet)
Windows
If you used winget:
winget uninstall git-xet
If you used the installer:
- Navigate to Settings -> Apps -> Installed apps
- Find "Git-Xet".
- Select the "Uninstall" option available in the context menu.
If you manually installed:
- Run
git xet uninstallin a terminal. - Delete the
git-xet.exefile from the location where it was originally placed.
How It Works
Git-Xet works by registering itself as a custom transfer agent to Git LFS by name "xet". On git push, git fetch or git pull, git-lfs negotiates with the remote server to determine the transfer agent to use. During this process, git-lfs sends to the server all locally registered agent names in the Batch API request, and the server replies with exactly one agent name in the response. Should "xet" be picked, git-lfs delegates the uploading or downloading operation to git-xet through a sequential protocol.
For more details, see the Git LFS Batch API and Custom Transfer Agent documentation.