A blog on software engineering by Trevor Brown

Stop Excluding Editor Temp Files in .gitignore

Many of the open source projects that I rely on have large .gitignore files with rules for ignoring temp files that their contributor’s editors generate. Sometimes these rules are added to the .gitignore intentionally by well meaning developers, other times they are copied in from other repository’s .gitignore files, sometimes build tools generate .gitignore files that contain these rules when generating new projects. It’s easy to see how repositories come to have editor-specific ignore rules in their .gitignore files. From ordinary libraries to massive open source projects like Electron ignore editor-specific files you will find editor-specific rules in the .gitignore file.

In this blog post I’ll explain why it’s unwise to try to ignore editor temp files with rules in a repository’s .gitignore file.

What’s wrong with excluding editor temp files in a project’s .gitignore?

Defining rules that properly exclude temporary files generated by text editors and IDEs can be very difficult if not impossible to do properly, and excluding temporary files for all editors is impossible. It may seem a little extreme to consider all editors when creating a .gitignore, but if your repository is open source or has many committers it’s possible that many different text editors or IDEs will be used. It’s hard to know ahead of time what tools the committers will choose to use. It’s much safer to have individual committers exclude the temp files generated by their own tools in their own global gitignore files.

The global gitignore

Creating a global gitignore is easy and the rules in the global gitignore will be applied to every repository you work on. To setup a global gitignore create file somewhere on your file system with rules to exclude the temporary files generated by your editor (I use ~/.gitignore_global. See my dotfiles for more details). Then run:

git config --global core.excludesfile <path to the file you created>

That’s all you need to do. Every rule you defined in the global excludes file will be ignored in every repository to you work on. The git config command will add a line to your .gitconfig file in your home directory that will look like this:

excludesfile = ~/.gitignore_global

You can edit your .gitconfig manually if you prefer.

But why not ignore editor temp files in each .gitignore to be safe?

Properly ignoring all temp files for an editor isn’t always as simple as it might seem. Take for example Vim, often you will find .gitignores with a single line like this intended to ignore all Vim swap files:


This rule is similar to the rule you would get in a StackOverflow answer if you asked about this on there. But this ignore rule is wrong. Vim’s swap files may have the .swp extension, but they may also have many other extensions as well. StackOverflow answerers aren’t the only ones who get this wrong, also gets it wrong. It takes multiple rules to exclude all Vim swap files:


In other words, Vim swap files don’t just have the extenions .swp or .sw*, they could be *.saa or *.sab if the other extensions have been taken. Here is the source code that generates these extensions if you are curious. And because these rules for excluding Vim swap files are so broad, they will exclude files that might not be swap files at all. For example, a file ending in .swf may be a Shockwave Flash file, but it will be ignored by these Vim swap file rules.

Worse still, some editors allow you to customize the names of the temp files they generate. This makes it impossible to define rules in a repository’s .gitignore that properly exclude editor temp files, even if you are only targeting a small set of editors and IDEs. It’s far better for developers to define their own rules to exclude their own editors temp files.

What’s wrong with trying to ignore what we can?

The problem is ignoring what you know about will result in most things being ignored most of the time. Most temp files will be caught by the rules and ignored. But from time to time a temp file might slip through and get staged or committed. If no editor temp files are ignored by the repository’s .gitignore it will be more clear to the developer that their Git configuration isn’t excluding files it should. This will prompt them to add more ignore rules; hopefully in their global ignore file.

But then contributors will check in their temp files!

Most will notice their mistake. And the few that don’t can be asked to remove the temp files from their PR. We get several PRs a week for asdf, many from new contributors, and I have never once seen a contributor accidentally check in a temp file. The asdf .gitignore file does not ignore any editor specific files and we have never had any trouble with this.


My approach to ignore rules is very simple.

I put any ignore rules that are specific to the tools I choose to use in my global ignore file. Any ignore rules that are specific to the language or tools required by a project I put in the project’s .gitignore file.



Erlang Cheatsheet

Erlang cheatsheet webpage screenshot

I have been writing Erlang for over 4 years now and there are still a few things I struggle to remember. Remembering all the core concepts is easy but it can be hard to remember the nuances of exit signals or exit trapping. Through the years I have cobbled together some notes on the things I found hard to remember, and I finally compiled them all into a presentable format. I created a printable cheatsheet from my notes that documents the easily forgotten quirks of the language. This cheatsheet isn’t intended for beginners because it does not cover any of the fundamentals of the language.

The cheatsheet is available for you to freely print or download at The source code has been released under the MIT license and is available on GitHub at Stratus3D/erlang-cheatsheet.

I’d really like to hear your thoughts on the cheatsheet. Is there something my cheatsheet is missing? Is there something that can be simplified or removed? What do you think of the design?

Let me know via email or twitter. If you want to contribute directly feel free to create an issue or pull request on the GitHub repository.



Why Erlang?


With web applications today there is an increasing need for systems that can scale up easily and tolerate the network, hardware, and software errors that occur at scale. Building such systems is challenging, if not impossible, to do in many popular programming languages today. Erlang was designed for telephone systems where uptime requirements were law, and as such was designed to solve these challenges. In this talk Trevor will show how Erlang can be used to solve some of the most challenging problems software developers face today. He will introduce concurrency constructs that Erlang provides and show how they can be used to build reliable and scalable applications. This talk will focus mostly on the new concepts introduced by Erlang, but Trevor will also do a few demos and show code samples to illustrate some of the concepts.