Dotfiles feel too personal to share

Privacy, Sensitivity, and “Intimacy” of Dotfiles

• Many feel uneasy publishing dotfiles because they expose hostnames, IPs, paths, RSS feeds, backup scripts, recent files, and other behavioral traces.
• Others describe a more emotional discomfort: dotfiles feel like a messy private sketchbook full of hacks, jokes, swears, and half-broken experiments, unlike polished professional code.
• A minority think this is overblown, arguing almost nobody reads random dotfile repos and comparing the concern to extreme nerdy self-consciousness.

Strategies to Separate Public and Private Content

• Common pattern: split into public vs private layers. Examples:
  • Public “base” files that source private, machine- or employer-specific files.
  • Large .gitignore sections to exclude sensitive or noisy configs.
  • Secrets moved into untracked files (~/.secrets), password managers (e.g., 1Password URLs), or separate private repos.
• Several tools are discussed:
  • Chezmoi (with gpg/age encryption, partial-file encryption, secret scanning via gitleaks, merge-all for drift, and editor integrations).
  • Nix + home-manager, myba, custom “context” systems, simple git+cron setups.
• General advice: categorize into secrets/env, local overrides, and generic shareable config; only the last should be public.

Value and Culture of Sharing

• Many say they’ve learned a lot from others’ dotfiles (e.g., shell aliases, vim functions) and rarely clone wholesale, instead copying small ideas.
• Some enjoy being able to answer “How did you set that up?” with a single repo link; others feel compelled to clean and document configs before publishing.
• Several recommend being generous with dotfiles, especially for mentoring newer developers.

Defaults vs Customization and Remote Machines

• Ops/SRE-leaning commenters often avoid heavy customization (especially editor plugins) to stay effective on bare remote servers, leaning into defaults as a “zen” practice.
• Others strongly reject this, arguing it’s worth investing in a tailored environment and bringing it along (sync’d dotfiles, sshrc-style tricks, containers, Emacs/TRAMP), especially for dev-heavy workflows.

Security and Threat Modeling

• Many emphasize keeping secrets out of dotfiles even in private repos; dotfiles can aid social engineering and fingerprinting.
• A security researcher argues the larger risk is supply-chain compromise via package managers (Homebrew, pip, nix, etc.), claiming that once those are in use, public dotfiles add little incremental risk.
• Some readers find this stance alarmist but accept that supply-chain attacks on package ecosystems are real and increasing.