Git server hook to silently ignore changes to specific files

Question

On a central git repo, I need to ignore changes to specific files when they are pushed to the repo. I don't want to reject (fail) the entire push, but simply ignore those changes. Is there a git hook I can use that will simply filter out some changes?

I thought about using filters, but I'm not sure they will get used on the central repo as it is "bare", eg., does not have a working copy.

Details: In a scenario similar to this, dozens of devs are pushing changes to those files. I tried using git update-index --assume-unchanged on the central repo, but it gets reset by every push done by a "stray" dev, which is then propagated to the rest of the devs when they pull. I can't change all the devs' repos at once. I want to make the change once on the central repo, then ignore changes to those files.

Answer 1

You simply can't do this, because excluding files from commits will change hashes. I mean you can do this, but you absolutely don't want it.

In your situation the most reasonable solution is actually rejecting commits that modify those files with meaningful errors like “You can't modify the following files: …” and educating your commiters.

Answer 2

This is technically possible, but it comes with huge practical hassles (not to mention the hook is fairly cumbersome to write): the client will still have the unfiltered history, and so at the next push it will look to the client as if the server has entirely different history from its own. The user will end up merging the filtered history with the unfiltered history, upon push that will in turn get filtered by your hook, and the story will keep on repeating.

For this reason, it's usually better to reject the hook or get all of your developers to install a pre-commit hook that does something comparable.

If you enjoy pain, here's an outline of how to do it in a pre-receive/update hook anyway:

• Check, using something involving git rev-list, whether any of the files in question were touched. If not, just bail out, because the next steps are going to be pretty painful.
• Temporarily checkout the history as it was prior to the push (this may be possible using the git-new-workdir contrib script).
• Figure out the list of new commits.
• Apply each of them, immediately amending away changes to the files in question.
• Get rid of the temporary checkout.
• Update the branch, and make the hook exit with non-zero code (this results in an error shown to the user, but you can send a nice message along with it). This prevents the normal push process from updating the branch itself and undoing your hard work.