Every package manager you use daily shares the same architecture. A central registry. A manifest format. A publish step. An install step. npm, pip, cargo, brew. The ceremony differs, but the shape is identical. And for managing complex dependency trees across thousands of packages, that architecture earns its weight.
But not every distribution problem is a dependency problem.
Sometimes you just need files in the right place. A set of config templates. A shared test fixture. A collection of Claude Code skills. A dotfiles repo you want to selectively pull from. For these cases, the full package manager apparatus is disproportionate to the task. You’re building a registry account, learning a manifest format, and running a publish workflow to solve what is a file-copying problem.
Git already solves most of this. Every repository has a name (its URL). It has versioning (commits, tags, branches). It has author identity (signed commits, if you use them). It has a content tree you can browse, diff, and fork. The only thing missing is an installer that respects a simple request: “I only want a slice of this.”
git from
git from is that installer. It treats any Git repository as a source you can selectively pull from. No registry. No manifest beyond an optional .gitfrom file (at the source). Just a repo, a target, and a filter.
The basic operation is straightforward. Point it at a repository, tell it what you want, and it copies those files into your working directory:
git from https://github.com/anthropics/skills --include skills/skill-creator --target .claudeThat pulls only the “skill-creator” skill from the repo, recreating the tree under “.claude” (the target). Nothing else comes along for the ride. You can combine --include and --exclude to carve out exactly the slice you need.
The .gitfrom file is where this gets interesting. It sits in the source repository and acts as a lightweight contract between publisher and consumer. It isn’t a new manifest format to learn. It’s saved CLI flags: which files to include, which to exclude, and what to run after copying. The publisher defines the default distribution, and the consumer can override it. Think of it as the agreement that says “here is what I intend to distribute and how.”
Then there’s --perform. This is the post-copy hook that turns git from from a file copier into an actual install pipeline. After the files land, --perform executes a Bash command. Symlink creation, permission changes, config generation, dependency installation. Whatever the setup requires.
The canonical example
Distributing Claude Code skills illustrates the model well. You maintain a repository of reusable agent skills. Each skill is a self-contained directory with its own prompt files and configuration. A consumer wants two of the twelve skills you publish. They run:
git from https://git.example.com/dx-team/dev-env --include "research/*" --include "review/*" --perform "./setup.sh"The right files land in the right place. The setup script wires them into the local environment. No registry. No publish workflow. The consumer got exactly what they asked for.
The trust model
I won’t sugarcoat it. --perform runs arbitrary Bash. There’s no sandbox, no permissions dialog, no verification step. Running git from <untrusted-repo> with --perform is the same threat model as curl ... | bash. This is by design.
Package registries provide real security value here. Code signing, vulnerability scanning, download counts as a weak reputation signal. git from offers none of that. If you don’t trust the source repository, don’t run --perform. Inspect the .gitfrom file first. Read the script. The tool is honest about what it does, and that honesty is the security model: no false sense of safety.
What this is not
git from doesn’t resolve dependencies. It doesn’t manage transitive installations. It doesn’t maintain a lock file or a dependency graph. If you need those things, use npm, pip, or cargo. They’re good at that job.
This fills a different niche. It’s for distributing reusable file sets where the overhead of a full package manager is disproportionate to the problem. Scaffolding, configuration templates, shared tooling, skill libraries. Things that have a clear publisher and a clear consumer, but no real dependency chain.
The simpler model
Publish by committing. Install by pulling a slice. The .gitfrom file is the contract. --perform is the setup step. Everything else is Git doing what Git already does.
The infrastructure was always there. Every repository you’ve ever pushed is already a distributable package. The only thing that was missing was a tool that treated it like one.
Package managers earned their complexity by solving hard problems. But not every distribution problem is hard. Some of them just need the right files in the right place. For those, the simpler model was hiding in plain sight.
