Git repositories as a module system: “git from” installs just the slice you need

What it does

Developers tired of the ceremony around package registries now have a lighter option. It has been reported that git from treats any Git repository as a distributable source and lets you copy only a “slice” of its tree into your project — no central registry, no manifest to learn, no publish step. Need a single test fixture, a handful of dotfiles, or two Claude Code skills from a dozen? Point git from at the repo, tell it what to include or exclude, and it copies exactly that. Simple. Practical. A little bit joyful, if you like trimming fat.

How it works

The UX is almost shockingly straightforward: specify a repo, include/exclude globs, and a target directory. Example: git from https://github.com/anthropics/skills --include skills/skill-creator --target .claude. There’s an optional .gitfrom file in the source that acts like saved CLI flags — defaults the publisher provides, which consumers can still override. And then there’s --perform, a post-copy hook that runs a Bash command to wire things up: symlinks, permissions, setup scripts. It has been reported that the tool intentionally avoids building its own manifest or dependency graph; this is for one-off distribution of files, not for resolving transitive dependencies.

Trust and limits

Here’s the emotional heart of the matter: --perform executes arbitrary shell. No sandbox. No permission dialog. No pretend security. If you run git from with --perform you’re basically doing curl ... | bash. That’s by design. Registries buy you things like signatures, scans, and reputational signals — git from gives you speed and minimalism instead. Want dependency resolution, lock files, or transitive graphs? Use npm, pip, or cargo. Want a quick, exact file copy from a repo without the fuss? git from is a sharp tool — just don’t hand it a loaded gun.

Sources: alnewkirk.com, Lobsters