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

["Kache Hit" <kache.hit@gmail.com>]

On Mon Nov 24, 2025 at 1:01 AM PST, Johannes Sixt wrote:
> A smudge filter must read its stdin and write the result to stdout. The
> presence of %f in the configuration does not change this.
>
> The filter can inspect the file name it receives via the %f token (note:
> the *name* of the file, not the file itself) to draw additional hints
> how to process the data, but it still has to read stdin and write to stdout.

Yes, I underststand. I'm asking why it's necessary that smudge not read
from disk, even as it properly satisfies that stdin/stdout operation, as
in my Python implementation of `smudge()`

On Mon Nov 24, 2025 at 1:49 AM PST, Chris Torek wrote:
> For sanity purposes, if no other reasons, it might be wise to store a
> "file with secrets" under a file with a name such that it is **never**
> controlled by Git (i.e., always listed in a .gitignore or equivalent,
> or outside the working tree entirely), and to store instead, in Git, a
> "template file with secrets that are replaced". That way, the secrets
> either exist on disk (and are secret because Git is blind to them), or
> do not exist at all (and are therefore secret to Git). The template
> file controls the template and nothing else; the secret-data file has
> both secrets and, perhaps, data that are extracted from the
> Git-controlled file as well.
>
> In this manner, a "to-be-smudged" file named foo.template might
> control some external-to-Git manipulation of an invisible-to-Gt file
> named foo.secret, and no clean filter would be required at all, though
> one could inspect and strip secrets accidentally copied into a
> foo.template.

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.

Although I could still apply that pattern by ignoring `foo.yml` and
committing a redacted `foo.template.yml`, I'd have to manually upstream
changes back to the template as the config file changes.

Another use case is to ignore changes to a specific line without losing
the working copy. Some software saves a volatile "last_updated_at" or
"last_opened" field into config that doesn't need to be committed. This
could also be useful for https://stackoverflow.com/questions/16244969
and https://stackoverflow.com/questions/61091219

- Kache