>GitHub should look into this, otherwise we get git repos with directories that are thousands in length.

In a way, Github already looked into it extensively while helping resolve the issue where CocoaPods monopolized their servers and hit CPU rate-limiting. Whether it's abusive or not was already debated ad nauseum when it happened, but either way they came to a set of solutions which might help anyone else wanting to use Github for package management:

http://blog.cocoapods.org/Master-Spec-Repo-Rate-Limiting-Pos...

This could work. There wouldn't be a need anymore for linking to the Git repo in an NPM package or similar. Maybe a special branch with a simple JSON file containing package data in the same repo as the main project.

Versioning and indexing becomes an issue -- this has to be entirely and completely separate from git repos and git branches. Playing with branches like that falls apart pretty quickly when you need to add real features that are expected by package maintainers.

http://bower.io/ does this in a sense by watching releases on a repository.