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.

On Sat, 21 Apr 2007, Junio C Hamano wrote:

David Lang [off-list ref] writes:

quoted

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.

I didn't miss it, I just don't think that the path in the repository is 
nessasarily as dangerous as the other things (time, branch, etc)

one thing that was listed as a possibilty was to use the sha1 of the file, but 
you would force the filter to calculate that itself. it's already available when 
extracting and recalcuating it is a waste

quoted

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.

what build procedures?

I'm talking about doing things like managing files in /etc

git doesn't have all the hooks to be able to set the permissions when you 
extract a file, but if the filters were actual readers/writers instead of 
in-memory operators, this becomes trivial to implement with no further changes 
to git itself

quoted

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.

actually, I'm thinking of much more complicated filters, where it's easier to 
have one program do both functions then it is to have two seperate programs 
(like tar -c /tar -x)

David Lang

On Sun, 22 Apr 2007, David Lang wrote:

On Sat, 21 Apr 2007, Junio C Hamano wrote:

quoted

David Lang [off-list ref] writes:

quoted

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.

I didn't miss it, I just don't think that the path in the repository is 
nessasarily as dangerous as the other things (time, branch, etc)

to clarify a bit more. I have a perl program that I can point at the 
'interesting' files on my systems and have it create a 'generic' version of that 
file. I can then take that generic version of the file to any machine in the 
cluster and with the same program create a version of that generic file that's 
correct for the other system. however to know which substatutions are 
appropriate to do for the file, it needs to know the filename (well, I guess I 
could create a whole bunch of seperate config files, and then define all the 
files with different filters, each filter including the config file to use fo 
rthat specific file, but this seems like a really ugly way to do it)

one thing that was listed as a possibilty was to use the sha1 of the file, 
but you would force the filter to calculate that itself. it's already 
available when extracting and recalcuating it is a waste

ignore this comment, I see you posted an example of this.

David Lang

On Sun, 22 Apr 2007, David Lang wrote:

On Sat, 21 Apr 2007, Junio C Hamano wrote:

quoted

quoted

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.

actually, I'm thinking of much more complicated filters, where it's easier to
have one program do both functions then it is to have two seperate programs
(like tar -c /tar -x)

Just specify the same program in both entries with the appropriate 
parameter and be happy.

It is much easier to have two entries with the same program than having 
only one entry when you actually have two separate programs.


Nicolas

On Sun, 22 Apr 2007, Nicolas Pitre wrote:

On Sun, 22 Apr 2007, David Lang wrote:

quoted

On Sat, 21 Apr 2007, Junio C Hamano wrote:

quoted

quoted

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.

actually, I'm thinking of much more complicated filters, where it's easier to
have one program do both functions then it is to have two seperate programs
(like tar -c /tar -x)

Just specify the same program in both entries with the appropriate
parameter and be happy.

It is much easier to have two entries with the same program than having
only one entry when you actually have two separate programs.

agreed, this is why I said that this was a fairly minor thing.

David Lang