Re: Management of opendocument (openoffice.org) files in git

[Sergio Callegari <sergio.callegari@gmail.com>]

Johannes Sixt wrote:
>
> You don't need a temporay zip filename in filter mode:
>
>   unzip $UNZIP_OPTS /dev/stdin  # works for me, but not 100% portable
>   zip $ZIP_OPTS - .             # writes to stdout
>
>   
The unzip documentation says "Archives read from standard input are not 
yet supported", so I was a bit worried about using the /dev/stdin 
thing.  Might it be that there are subtle cases where unzip needs to 
seek or rewind?
>> then put in your .git/config something like
>>
>> [filter "opendocument"]
>>         clean = "rezip -p ODF_UNCOMPRESS"
>>         smudge = "rezip -p ODF_COMPRESS"
>>     
>
> Is the smudge filter really necessary? Can't OOo work with files at
> compression level 0?
>   
Yes, you can live perfectly without smudge.  But at times it is not that 
nice. Just think of finding a directory with say 15 lectures as impress 
slides taking 10 times the space it needs, particularly if you need to 
pass those files to someone else. As a matter of fact, ODF xml is very 
verbose and compresses particularly well having long tags.
But you might want to compress -1 rather than the default in smudge to 
speed it up a little.  Can be done either adding a new profile to the 
script (say ODF_COMPRESS_FAST) or by adding --zip_opts -1 to the smudge 
command line.
Also, we might want to add some -n suffixes to zip, to prevent it from 
trying to compress a few things like .png or .jpeg images and that have 
their own compression.  That should gain us some speed in smudging.

In any case - but this is just my feeling - it is much more disturbing 
the delay that the clean filter introduces in operations like add or 
status or commit, than the one introduced by the (slower) smudge filter 
in checkout.  There must be some psychological reason for that.  
Possibly we are "programmed" to accept waiting when we need to get 
something and conversely we are impatient when someone should accept 
something from us.

Sergio