Only basic knowledge of git and command line usage/git UI is required
Have you ever worked on a project and seemingly out of nowhere your entire file list in your git staging history? It’s ugly, it ruins any usefulness your current commit had, and can clog up your overall history pretty fast. For a while, I wasn’t even sure what caused this. Turns out, changing file permissions of a file(or directory of files) makes it trackable by git. Luckily, avoiding this issue is very easy. Let’s dive into it!
What’s Causing This?
In short, git will track a file permission change. For example, if you run
chmod 755 file.js, (if you aren’t a unix guy, this just changes
file.js to 755), git will start tracking and it will show up in “not staged for commit”. The problem worsens when you run a command like this recursively. It’s common to have file permission errors and just run
chmod -R 777 ./ to change multiple file permissions at once. Convenient, but suddenly you are met with a sea of red files and are stuck not knowing what to do. Luckily, there’s a handy option in git that can change this.
How To Fix
In short: run
git config --global core.filemode false . This will turn of file tracking for all repos, hence the
--global option. For me and probably most (front-end) developers, there’s no real reason to track file permission changes. If you need to, you can enable and disable this option based on a specific repo.
Not using the
--global flag only sets it for the repo you are on
git config core.fileMode false.
When I was scratching my head, this post is what helped me. It contains even more info about flags if you’re interested in reading into this option deeper! Just a quick and simple tip to make your development and git life easier.