Micromanaging my .config folder has allowed me to create a simple and effective install file so I can pull my setup into a new machine instantly, and modify my environment intentionally.
My previous method of TUI exploitation
I have dabbled with tmux and neovim on and off over the years. While I have yet to integrate it into my professional workflow, I do enjoy the slow development process for my personal projects (espcially in this hypersonic AI era). One of my fondest memories when I was first diving into code was making my terminal interface look cool, through projects like Oh My Zsh and dual booting linux distros on my tiny Lenovo Yoga I routinely pushed to the limits for my robotics team. I always made sure to back up my config files onto Github. This allowed me to get familiar with git early and have a better overview of the filesystems I was working with. This process was always fragmented and I regularly scrapped my work for something completely new. The result was three repositories, one for tmux, one for neovim, and one for zsh. All managed seperately, all disposable whenever I got bored.
My reaction to the AI developer “renaissance”
While I feel less threatened than I did initially, I generally run as a more anxious personality and try to keep up with all the new tools. Like many others, this has allowed me to spot patterns and convergence with the direction of the AI developer experience. My goal here is to make strides to leverage it in my own future-proof way. I have used VS Code pretty consistently since it replaced Atom as the best tool to get the job done. I have downloaded and tried out Cursor, Zed, Antigravity, and countless other spinoffs with their own flavor of AI integration.
Eventually, I switched my perspective towards seeing compute as a commodity. I (like many others) landed on wanting a solution that didn’t lock me into one LLM provider. Many of these systems allow provider switching, but I wanted something that couldn’t be locked down at some future date. This drove me back into neovim, and more importantly, OpenCode. Again, I scrapped all previous configurations, spun up my terminal environment, and committed to locking down a sustainable and intentional workflow for myself.
Using gitignore as a guardrail
Rather than pushing my entire nvim or tmux folder (located within my .config folder). I tried to zoom out and clear away anything that I didn’t have direct control over. This meant stripping these directories down to what I control, and building from there. The heart of this became my .gitignore file. I took a whitelisting approach to micromanage every file that truly needs to be modified. While there might be some redundancies, this is what I landed on:
# Ignore everything * # Allow the directories themselves !*/ # Allow the root-level files !.gitignore !new-terminal.sh # Whitelist config files !/zsh/.zshrc !/tmux/tmux.conf !/nvim/** !README.md # Blacklist the junk folders /zsh/.oh-my-zsh/ /zsh/custom/plugins/* /zsh/.zsh_history /zsh/.zcompdump* /nvim/doc/tags **/tmux/plugins/**/.gitignore **/zsh/custom/plugins/**/.gitignore /nvim/.gitignore /tmux/plugins/* /zsh/custom/plugins/* /tmux/plugins/* *.log *.swp .DS_Store
Ideally, this prevents me from adding unecessary things and forces me to think about only what is strictly needed to maintain my setup.
... continue reading