Git-Xet: moving the changed pieces
Chunk-based transfers and readable notebooks tackle two different obstacles to sharing research repositories.
Tools in this story
When a small revision moves a large file
A research repository can contain a short training notebook beside gigabytes of model weights. A collaborator needs to understand the changed experiment and retrieve its artifacts, but those are different jobs. Git-Xet addresses the transfer side: it is a Git LFS custom transfer agent for uploading and downloading through Hugging Face’s Xet protocol. The familiar Git workflow remains visible while the large-file transport changes underneath it. The upstream guide describes that boundary explicitly.
The useful distinction is file identity versus shared content. Two checkpoint files can have different identities while retaining some identical bytes. Xet divides content into chunks and identifies reusable pieces, so a revision need not resend everything that already exists remotely. Its protocol also specifies how stored pieces are assembled into complete files. That makes repeated, related artifacts an interesting workload; entirely different data offers less opportunity for reuse. The protocol specification explains the mechanism without requiring a universal speed claim.
A familiar name takes a new direction
Xet’s history predates its arrival on the Hub. Hugging Face acquired XetHub in August 2024, and its history documentation describes the move from whole-file deduplication toward reuse below the file level. The current client repository explicitly acknowledges its earlier codebase and a different backend implementation. This is a substantial change in deployment and audience, rather than evidence that the underlying project was invented recently. Xet history and the client repository establish that lineage.
The operational turning point came in 2025. In its July migration account, Hugging Face reported that 500,000 repositories holding 20 petabytes had moved onto Xet during six months. It also described the compatibility bridge that let older clients continue working. Those are the operator’s figures, and they describe the storage platform rather than adoption of the Git-Xet executable specifically. The migration report provides both scale and an unusually useful account of failures encountered along the way.
Where the executable is actually used
A concrete example is Hugging Face’s cross-region copying application. Its repository-copying worker fetches Git branches and tags, transfers large objects, and enables Git-Xet locally for the push phase. The implementation preserves repository content and history, while explicitly leaving settings such as privacy, hardware, and secrets for separate handling. This is evidence of an implemented operational workflow, although it does not establish how many people run it. The application README documents those choices.
That distinction matters when planning a migration. Moving bytes and commits does not reproduce the surrounding service configuration. A successful copy still needs a review of access settings and other repository behavior. For a team publishing related model revisions, Git-Xet is most relevant when Git is already the interface they want to retain. It adds little conceptual value to a workflow that never uses Git directly.
Make the notebook readable, too
Jupytext addresses the other half of the research repository. It stores notebook inputs as scripts or Markdown and can pair that representation with an ordinary notebook holding outputs. Reviewers can inspect a compact text diff while researchers retain an interactive notebook locally. Text-only storage omits results, so teams must decide which outputs deserve preservation. Jupytext’s repository explains the formats and pairing behavior.
This is an established companion: its changelog reaches back to the initial converter in June 2018. The release history shows years of development around notebook conversion. Pairing it with Git-Xet is an editorial workflow suggestion, not a claimed integration between the projects. One improves the representation people review; the other improves how large artifacts travel.
Evaluate the whole round trip
Git-Xet requires configured Git and Git LFS. Python users may already reach the same storage through huggingface_hub, so they should check their existing path before adding another tool. Hugging Face’s usage guide distinguishes those entry points.
A useful evaluation would compare a first upload, a representative revision, and retrieval on another machine. Record transfer time, local resource demands, and whether the resulting repository contains the expected files. Separately, review a notebook change and confirm its retained outputs still make sense. These are suggested checks, not benchmarks performed for this article. The practical goal is a repository that collaborators can both understand and retrieve, with clear boundaries around what each tool preserves.