git
Mining my Git repositories
Since I started using Git, I’ve been finding myself creating tons of repositories. Anything I think might someday prove interesting or that I work on for more than a few minutes, I create a Git repository. I’ve yet to discover that ultimate workflow, but between experimenting with using it to put presentations online, managing the Dallas.rb website via Git and using it extensively at FiveRuns, Git is proving quite fun.
But let’s get back to that earlier point: I have a metric shit-ton of repositories laying around in my home directory. This morning I found myself wondering exactly how many I have and how many actually have a remote (i.e. how many have yielded a project worth backing up remotely and/or sharing). So, I did the numbers:
| Directory | Repositories | Remotes |
|---|---|---|
| @/Users/adam@ (Home, sweet home) | 287 | 263 |
| @~/FiveRuns@ (Work stuff) | 161 | 160 |
| @~/repos@ (All source-ish stuff) | 85 | 69 |
| @~/repos/sources@ (Interesting code of others) | 62 | 60 |
| @~/repos/projects@ (My own code) | 9 | 6 |
| @~/Desktop@ (Landing pad for the newest of projects) | 1 | 0 |
Which is about what I’d expect in terms of quantity and ratio. I’m a little surprised I have so many work repositories laying around, but we use submodules extensively so there’s probably only about 40 repositories that are meaningful to us. I’m a little suprised that so many of my personal projects do have remotes though. I guess I’m making progress towards doing more.
For those interested, the script that begat all this fun data. Run it yourself and share your numbers!
git.repo.revs.each(...)
Git Iterator - a neat little gizmo for running code against every revision in your Git repository. Yielded this chart showing the growth of the Rails code.
Changing git submodule URLs
Pro-tip: if you’re using submodules with Git to manage dependencies (say Rails plugins), you can get yourself into trouble. Like half-a-day of wasted trouble.
The rub comes when you need to make a change to some plugin. Suppose you were using Brain Buster for your captcha and then decided you need to make a change. The @git submodule@ command doesn’t really seem to offer a way to change the URL for the submodule. Let me summarize what I’ve found in trying to do this.
h2{color: #f00}. The Wrong Way
- Fork/create your own version of the submodule in question
- Change the URL for the submodule in @.git/config@ and @.gitmodules@
- Cross your fingers and hope for the best
h2. The Right Way
- Fork/create your own version of the submodule in question
- Remove references to the existing submodule in @.git/config@, @.gitmodules@ and nuke the submodule directory
- Commit
- Add the new submodule URL
- Commit
- Make changes in your submodule
- Commit changes in the submodule (not the parent project)
- Commit the changes in the parent project (otherwise you’ll only get the old version of the submodule in future pulls)
- Enjoy the hair you didn’t have to rip from your scalp
Learn from my mistakes, people.
Git is nouns and verbs
Git was originally not a version control system; it was designed to be the infrastructure so that someone else could build one on top. And they did; nowadays there are more than 100 git-* commands installed along with git. It's scary and confusing and weird, but what that means is git is a platform. It's a new set of nouns and verbs that we never had before. Having new nouns and verbs means we can invent entirely new things that we previously couldn't do.