There's a moment when you clone or pull a repository on Windows and Git throws an error like this: error: unable to create file some/very/deeply/nested/path/to/a/file.ts: Filename too long
Nothing wrong with your code, nothing wrong with the repo. It's Windows.
Why does this happen?
Windows has a default path length limitation of 260 characters (the infamous MAX_PATH ). Git operations that create files with a full path longer than that — cloning, checking out, pulling — will fail with this error. Repositories with deeply nested folder structures (think node_modules, or generated code) hit this constantly.
The fix: enable long paths in Git
Git has a config setting for exactly this: core.longpaths . You have two ways to set it, depending on your rights on the machine.
System-wide (requires Administrator privileges):
git config --system core.longpaths true
User-level (no Administrator required):
git config --global core.longpaths true
If y...
Recently I was wiring up a YARP reverse proxy in front of a couple of Aspire-managed services: an API and an Angular frontend. Aspire gives you service discovery for free, so the obvious move is to point your YARP clusters at the logical service names instead of hardcoded URLs. My first attempt looked like this: "Clusters": { "api-cluster": { "Destinations": { "api-destination": { "Address": "https+http://api" } } }, "frontend-cluster": { "Destinations": { "frontend-destination": { "Address": "https+http://angular-frontend" } } } }
The https+http:// scheme is the standard Aspire service discovery convention: try HTTPS first, fall back to HTTP. It works fine when you're resolving endpoints through HttpClient .
Unfortunately YARP doesn’t like this configuration. After setting it up with these values ...