Best approach for pre-processing files before committing to Git?

Question

I've never had reason to investigate the usage of git hooks before so I'm coming at this with very little information.

My general scenario is that I want to parse certain file types automatically when committing them to the repository. The specific scenario is related to MIT Scratch. Entire projects are stored as SB3 files (which are actually zip files). The zip file contains all the graphic and sound assets as well as a project.json file which contains all of the scripts contained in all of the sprites. The JSON isn't very legible as Scratch is a block-based language which doesn't lend itself to being easily read.

I've written a PHP tool which parses the JSON file into readable text scripts contained in each of the sprite. What I would like is to automatically process SB3 files when they are committed so that my tool is triggered, parses the JSON file within the SB3 (ZIP) and then commits a separate text file for each sprite contained therein (as well as committing the actual SB3 file).

As an example, consider one of my projects, my Scratch BBC Micro emulator. If you enter the project number (515569918) into my parsing tool then you can see the output that I want automatically committing alongside the actual SB3.

Is this something that can be achieved with git hooks and, if so, could someone provide a general overview of the implementation process please?

If git hooks are the wrong approach, any suggestions would be welcome. There is little point in a repository containing just the sb3 as it's a straight binary zip file. The only real use is to extract everything first and, even better, use this approach of parsing the JSON file within the zip file before committing.

Answer 1

A pre-commit hook can make adjustments to Git's index. (Git makes commits not from the files in your working tree, but rather from what is in Git's index.)

It is unwise to use a pre-commit hook in this way for two reasons:

1. It surprises users.
2. Some commits are made with more than one index involved, in which case the results are never good.

In short, don't do this. If you want to use a Git back-end to make commits that users aren't really aware of, do that instead, with the user working in some space where things are not so surprising.

For other tasks, see Git's smudge and clean filter technique. Whether that applies here, I have no idea. Note that this filters run independently of any Git hooks.