[Kde-games-devel] committing svgz and png to git

Parker Coates coates at kde.org
Mon Sep 10 11:35:00 UTC 2012


On Sat, Sep 8, 2012 at 10:36 PM, Wolfgang Rohdewald wrote:
> now that all those files in the git repositories will be optimized
> (svgz with compression level 0=no compression, png with optipng and advdef)
>
> what happens if I commit svgz / png changes without applying this optimization
> to my files first? The repo will certainly grow if I replace an uncompressed svg
> with a compressed copy.

That is why I wanted, to convert the files to plain SVG: to guarantee
that compressed copies are never commited. But because SVG files are
so much larger to ship and slower to load than SVGZ, I wanted to
compress them as part of the build. I still haven't got there though,
and probably won't in the immediate future.

The PNGs are what they are. The main reason I did the recompress
script for the Git migration was just to avoid storing multiple copies
of the same PNG due to the repository-wide optipng runs done in the
SVN days. Any extra savings were just a bonus. Ideally, everyone would
optimise their PNGs before committing, but that's not likely to
happen. The important thing is that nobody does any optimisation-only
commits any more.

> I can define commit hooks doing that locally, but what if somebody does not
> define them? Shouldn't there be commit hooks on the server for this
> transformation?

>From my (limited) understanding, server-side hooks can only reject
pushes or react to pushed commits. They can't actually change the
contents of a commit, because that would change the hash and cause the
commits on the server to be different from those in the pusher's
repository.

You could write a pre-commit hooks to optimise PNGs before they get
committed locally, but, yes, each developer would be responsible for
using them. It still seems like a good idea though. :)

Parker


More information about the kde-games-devel mailing list