Joey Hess <id@xxxxxxxxxx> writes: > Junio C Hamano wrote: >> 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. That's a fair point. > 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. And yes, "clean-from-fs" that is spawned by us with the name of the file in the filesystem that has the contents as its argument, must be prepared to see a filename that does not have any relation to the filename in the working tree. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html