From: Johannes Sixt Date: Mon, 24 Nov 2025 09:01:19 GMT Subject: Re: Filter smudge for secret restoration: no disk access? Message-ID: <9aa7cfdb-fc50-4ceb-936c-2ed441c462a3@kdbg.org> In-Reply-To: Am 24.11.25 um 08:39 schrieb Kache Hit: > 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