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.jsfile.js755), 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 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.-R 777 ./
How To Fix
In short: run git config --global core.filemode false--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 --globalgit 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.
![[Demo] Defining Reusable Column Extends with SCSS](https://bparkerproductions.com/wp-content/uploads/2023/09/demo-defining-reusable-column-extends.png)
Comments