Re: [PATCH 4/4] Add 'filter' attribute and external filter driver definition.

David Lang [off-list ref] writes:

1. it would be useful in many cases for the filter program to know
what file it's working on (and probably some other things), so there
are probably some command-line arguments that should be able to be
passed to the filter.

I can see that you missed the class when Linus talked about how
messy things would get once you allow the conversion to be
stateful.  I was in the class and remembered it ;-)

Although I initially considered interpolating "%P" with
pathname, I ended up deciding against it, to discourage people
from abusing the filter for stateful conversion that changes the
results depending on time, pathname, commit, branch and stuff.

2. should this be done as a modification of the in-memory buffer (s
this patch does it?) or should it be done at the time of the
read/write, makeing the filter be responsible for actually doing the
disk I/O, which would give it the benifit of being able to do things
like set permissions and other things ...

The conversion is not about overriding the mode bits recorded in
tree objects, nor making git as a replacement for build procedure.

3. why specify seperate clean/smudge programs instead of just one
script with a read/write parameter?

I think the most common two ways have clean as a cleaner and
smudge as a no-op (similar to crlf=input conversion), or clean
and smudge are inverse operations (similar to crlf=true
conversion.  I do not see a sane case where clean and smudge are
the same, unless you are thinking about the toy demonstration
test piece I added to t0021 which uses rot13 as both clean and
smudge filters.