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

From: Joey Hess <id@joeyh.name>
Date: May 12, 2016, 20:46 UTC
Message-ID: <20160512204634.GA9292@kitenet.net>
In-Reply-To: <xmqq7fezdoe7.fsf@gitster.mtv.corp.google.com>

Junio C Hamano wrote:

Show 7 quoted lines

> This side, I do not think we even need a new variant.  We can just
> update the code to interact with "clean" so that it the writer to
> the pipe ignores SIGPIPE, detects EPIPE on write(2), says "ah, the
> other end does not need the full input to produce its output".  The
> reader from the pipe consumes its output without failing AS LONG AS
> the "clean" filter exits with zero (we do check its exit status,
> right?)

There are two problems with doing that. First, any clean filter that relied on that would not work with older versions of git.

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. For example, git hash-object --stdin --path=whatever. So the current clean filter can't really safely rely on accessing the file to short-circuit its cleaning. (Although it seems to mostly work.. currently..)

> We cannot do a similar "we can just unconditionally update" like I
> said on the "clean" side to "smudge", so it would need a new
> variant.  I do not want to call it anything "raw", as there is
> nothing "raw" about it.  "smudge-to-fs" would be a better name.

"raw" was just a placeholder. "clean-from-fs" and "smudge-to-fs" are pretty descriptive.

-- 
see shy jo