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

From: Johannes Sixt <j6t@kdbg.org>
Date: Nov 24, 2025, 09:01 UTC
Message-ID: <9aa7cfdb-fc50-4ceb-936c-2ed441c462a3@kdbg.org>
In-Reply-To: <DEGR5XSM0EVG.27IMOKOK1O98Y@gmail.com>

Am 24.11.25 um 08:39 schrieb Kache Hit:

Show 17 quoted lines

> I was working on a git redaction script that restores working copy
> secrets when applied via `.gitattributes` clean/smudge filters, but
> encountered `smudge` not having access to the "working file" on disk.
> 
> I see it's documented as intended in
> https://git-scm.com/docs/gitattributes:
> 
>> Note that "%f" is the name of the path that is being worked on.
>> Depending on the version that is being filtered, the corresponding
>> file on disk may not exist, or may have different contents. So, smudge
>> and clean commands should not try to access the file on disk, but only
>> act as filters on the content provided to them on standard input.
> 
> Any chance there's a way around this or some alternative? Python
> implementation below for reference.
> 
> And also for my understanding, why _shouldn't_ smudge access disk?

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.

-- Hannes