I work across multiple repositories. When you're juggling that many repos, it's easy to lose track of which one you're in. I kept finding myself squinting at the repo name in VS Code to make sure I wasn't about to make changes in the wrong project.
That's when I discovered Peacock, a VS Code extension that lets you change the editor color based on the project. A tiny visual cue, but a huge time-saver when you're context-switching all day.
The problem
The problem? One of our repos doesn't ignore the .vscode/settings.json file. So every time I tweaked Peacock's colors, Git would flag .vscode/settings.json as modified. Before committing, I had to manually stash or reset those changes so I wouldn't accidentally push them upstream.
I didn't want to touch .gitignore since teammates rely on committing shared project settings. What I needed was a way for Git to quietly ignore my tweaks without disrupting the repo for everyone else.
The Command That Saved My Sanity
After some digging, I learned about a neat trick:
# Tell Git to ignore local changes to this file
git update-index --skip-worktree .vscode/settings.json
From that point on, Git acted like the file was untouched, even if I completely changed the colors inside it. When I rangit status, nothing showed up. No more accidental commits, no more manual cleanup before pushing.
And if I ever need Git to notice changes again:
git update-index --no-skip-worktree .vscode/settings.json
When to Use It
Use --skip-worktree
When:
- The repo includes files that should be tracked, but your local edits aren't relevant to anyone else (like editor configs, test configs, or local scripts).
- You want to keep your workflow smooth without constantly cleaning up changes before commits.
Avoid it when:
- You need to collaborate on that file with your team.
- Forgetting about the "skip" could cause important updates to be missed.
Final Thoughts
Peacock solved my repo-switching confusion. And git update-index --skip-worktree solved the annoying "settings file keeps showing up in git status" problem. Together, they've made my day-to-day dev flow smoother.
Sometimes it's not about the big tools or frameworks - it's the little tweaks that save you the most brain cycles.
Top comments (0)