Re: Filter smudge for secret restoration: no disk access?

From: Chris Torek <chris.torek@gmail.com>
Date: Nov 25, 2025, 08:55 UTC
Message-ID: <CAPx1GveYzEs_iAo2oV2OgoGbJJfw4Q0VVzRApEwCOMUAAY_v1Q@mail.gmail.com>
In-Reply-To: <DEH58DEF5MGO.2CFIKCM2CAQY2@gmail.com>

On Mon, Nov 24, 2025 at 10:40 AM Kache Hit <kache.hit@gmail.com> wrote:

Show 6 quoted lines

> I'm familiar with this practice, e.g. committing an `.env.template`
> which is used to create an `.env` file with secrets within.
>
> However, this is my dotfiles repo that includes `~/.config`. There are
> config files that store credentials right next to configuration, managed
> by software that I don't control.

My technique for this is that my dotfiles are in a repository where they are named "profile", "bashrc", "gitconfig", and so on. These get installed by my dotfiles-installer as $HOME/.profile, etc. The installer (my own creation, tuned to my personal needs and not really suitable for anyone else) builds the target files as needed.

(The thing probably needs a redesign and rewrite since newer software messes with these files more dynamically at this point, but I have not had to do that yet. So far I haven't needed to do the "update repository from active files" part, which would be harder.)

The reason for naming them without the leading dot is to make it abundantly obvious during editing whether I'm on the template or the actual config file.

As you've seen, there are more issues with going back in history (to points where various files didn't exist yet). This sidesteps most of these.

Chris