It turns out that git offers three mechanisms to specify which files to ignore. Most people know about the .gitignore files inside the working tree. But if you take a look at the gitignore documentation you’ll find out that there’s a second file to specify ignore patterns that are specific to a given user’s work-flow, but that shouldn’t be cluttering the .gitignore files inside the repo, which are normally also versioned by git and thus shared by all the developers working in the project. Patterns like these should go in the $GIT_DIR/info/exclude file, where $GIT_DIR usually refers to the .git/ directory inside your working tree.

Nobody cares what’s your favorite editor and you shouldn’t be cluttering the ignore files versioned inside the repo with the patterns of the files generated by your working environment. That way your buddies on a Mac won’t laugh at you when they notice you are stuck with Netbeans because you’re on Linux, or that you are geeky enough to use Emacs or Vim instead of the sexy TextMate.

But wait. We still have to repeat all those pesky private ignore patterns in every different project, when we should be able to tell git globally about the garbage we normally want to ignore. DRY anybody?

You’re right. That sounds very stupid. We are programmers after all. We’re supposed to be clever and lazy. So is the guy who invented all this git thing. It turns out that you can specify a global .gitignore file via git-config.

git-config --global core.excludesfile /Users/ernesto/.gitignore

The file doesn’t have to be named .gitignore and it doesn’t have to be in your home directory. The core.excludesfile configuration directive is there precisely so that you can put this global ignore file anywhere you want. Also, beware of using ~/ to specify that the file is in your home directory. The documentation says that it works and expands it to the value of the $HOME environment variable, but it doesn’t work in my Mac.

So now you can go and edit that file and put the things that bother you privately. Mine for instance is something like this.

.DS_Store
.svn
*~
*.[oa]
*.kpf
nbproject
Thumbs.db

Currently it works as a Ruby interface to Mercurial, but they are aiming high. According to their own definition, “[their] goal is to produce a piece of software that lets you forget that you’re working on git project one moment and a Mercurial project the next.” A sort of meta-interface for most modern distributed VCS’s out there, so that you can use them all with the same set of commands, or maybe even interact between different VCS’s. Although I haven’t had the time yet to truly play with it, It appears to be highly customizable.

BTW, they also mention svn and cvs as VCS’s they want to support, but I can’t see why to drain out resources into these dinosaurs. I still don’t get why people still use centralized-only VCS’s if they have the choice of distributed version control. But anyway, I wish them good luck with the project overall, and I will sure keep an eye on it for a while.

So far (the short version) I am doing better than I thought for just about a couple of days being serious about this. There are a few things that still bother me a lot though, aside from the fact that I am not proficient using it yet, of course.

My [mostly borrowed] customizations

I’ve heavily customized Emacs to suit my needs better than it could do with its awkward defaults. Emacs key shortcuts (or is it key bindings?) are soooo unpleasant, unintuitive, lengthy and annoying that I refuse to use them at all. Happily one of Emacs’ most powerful strengths, its ability to be customized, comes to the rescue. Actually this feature is what makes Emacs still relevant after 30+ years.

My Emacs after being customized

Without going too much into details, I based my Emacs customizations mostly on Ryan McGeary’s, mostly because his setup is aimed at Ruby on Rails development and Git, which is what I want Emacs for in the first place. Overall, it’s ri-emacs, rinari, rhtml-mode, magit, yasnippets, and several other non-language-specific customizations (ido, recentf, etc.)

On top of this setup, and after pruning stuff that I don’t need, at least for the moment (like erlang, markdown, haml, svn, carbon-emacs, etc.) I added support for some other stuff, namely rspec, cua-mode (see Common User Access), and other minor goodies from other sources.

Aside from McGeary’s setup as a base, I have to give credit to snippets of code I borrowed from elsewhere to further customize my environment. I should particularly mention Devcraft’s advises to customize Emacs for Rails development, Dahoiv’s .emacs file, the Emacs blog (where Ryan McGeary also writes) and the emacs-flu blog.

Pros and Cons

On the good side, I have played for a while with the ruby on rails mode and it is good. The yasnippet extensions take a lot of credit on this, but overall it tastes very good on its own. I have yet to deal enough with the magit extension to fully evaluate my environment. I cannot afford buying a Mac+TextMate for Ruby development, and Emacs can hopefully come to the rescue for my productivity and joy while coding.

Also, having been able to get rid of most of the many painful key bindings in such a short time was amazing. I wonder why Emacs does not update its defaults to comply with the CUA standards. The cua-mode is not enough.

On the bad side (taking aside my own inexperience and lack of abilities) not everything is doing fine. Many of my key-bindings customizations break on “weird” modes, like C-w for closing the current buffer, which is not working when the current buffer is in dired mode.

Also, I feel disappointed with the embedded shell (M-x eshell). I actually expected a bash session inside an Emacs window, but aliases and tab-completion are not working as they should, which makes me suspect it is not bash but an Emacs shell program (surprise!!!). As it is right now, I prefer to Alt-Tab to my terminal emulator with a real bash session in it. Something similar happens with the Rails console (available via C-c ; c), which I really didn’t test a lot after I realized that pressing the up and down arrow keys didn’t navigate through my history of previous commands .

So, what is it then?

In spite of all this, I still believe I can give Emacs a chance. Most shortcomings I’ve faced are not directly related to its function as a coding environment, but to tasks around coding, like going to the console to type rails-related commands, manipulating the file system, etc. I was doing these stuff outside my previous code editors anyway so I guess this can stay as is for some time.

Hopefully I’ll be able to fix some of this issues over time and always use more and more features of this wonderful editor. I could even live without using git from within it, but I have yet to test that. Meanwhile, I’ll take some time to get better at coding with what is currently working for me. It seems to me that Emacs will stay for a while on my desktop.