I guess it's a tradeoff. A bloated history sucks for sure. So does maintaining brittle legacy code that has to change often. It's a tradeoff between a bloated r

I guess it's a tradeoff. A bloated history sucks for sure. So does maintaining brittle legacy code that has to change often. It's a tradeoff between a bloated repo and being able to easily bisect issues from arbitrary points in the projects history. I was hoping you knew of some tool that maintains the dependencies separately while correlating them with specific commits in the main repo. It's nice being able to just checkout arbitrary commits and have it just work. In one project there was dozens of package.json files. I committed the node_modules as a short term hack to get a one step build. It makes git very slow but it was worth the tradeoff for this particular project. Another issue is node gyp since its platform specific, you don't want to be committing mac specific stuff when some team members use Linux. Managing dependencies can really suck sometimes. Another consideration is deployment. In my experience deploying using Capistrano and git is often faster than rsyncing a bunch of files or copying from s3 or wherever. My conclusion for this project is yes it sucks that our repo is now bloated. But maybe that should suck. Maybe it makes us more cognizant of our dependency issues. Maybe having tons of deps should cause you pain, as motivation to more carefully consider your dependencies