If any functionality exists in .git/hook/pre-commit prior to running secureli init, we should not remove the preexisting functionality. Instead, we should integrate logic from secureli with the existing pre-commit hook code.

Note that we will want a way to identify any logic added via seCureLI so that we can make changes to it (e.g. updates) without affecting non-secureli logic.

Here are a few ways this could be implemented:

1. (Easier but less correct) we could back up the state of .git/hooks/pre-commit at secureli install time. Any time we need to make a change/update to the hook, we can append the new logic onto the backup file. This won't account for any changes manually made to the pre-commit file after secureli was installed.
2. (Slightly more difficult) we could add some delimiter (e.g. #### BEGIN seCureLI ####/#### END seCureLI ####) to indicate sections of the pre-commit file managed by seCureLI.
3. We could have a single line in the pre-commit file that executes a separate script managed by seCureLI. Then we could rewrite/regenerate this script for any updates, and avoid making any additional changes to the pre-commit hook.