Re: proposal for extending smudge/clean filters with raw file access

From: Joey Hess <id@joeyh.name>
Date: May 12, 2016, 21:17 UTC
Message-ID: <20160512211752.GB10786@kitenet.net>
In-Reply-To: <xmqqy47fc7y7.fsf@gitster.mtv.corp.google.com>

Junio C Hamano wrote:

Show 8 quoted lines

> > Secondly, and harder to get around, the filename passed to the clean
> > filter is not necessarily a path to the actual existing file that is
> > being cleaned.
> 
> Either one of us is confused.  I was talking about updating the
> current "clean" implementation without changing its interface,
> i.e. gets fed via its standard input, expected to respond to its
> standard output.  There is no filename involved.

I'm talking about the %f that can be passed to the clean filter. The context that I left out is that my clean filter could avoid reading all of stdin, and quickly produce the cleaned result, but only if it can examine the file that's being cleaned. Which is not currently entirely safe to use the %f for.

There may be a way to make a clean filter that can do something useful without reading all of stdin, and without examining the file that's being cleaned. Maybe. Hard to see how. I don't feel such a hypothetical clean filter is worth changing the current EPIPE behavior to support.

So I think it's better to add a separate clean-from-fs and keep the current clean filter interface as it stands.

-- 
see shy jo