Git Hooks for File System Monitoring and Submit Validation

version (1) and the time in elapsed nanoseconds since midnight, January 1, 1970. Version 2 takes two arguments, a version (2) and a token that is used for identifying changes since the token. For watchman this would be a clock id. This version must output to stdout the new token followed by a NUL before the list of files. The hook should output to stdout the list of all files in the working directory that may have changed since the requested time. The logic should be inclusive so that it does not miss any potential changes. The paths should be relative to the root of the working directory and be separated by a single NUL. It is OK to include files which have not actually changed. All changes including newly-created and deleted files should be included. When files are renamed, both the old and the new name should be included. Git will limit what files it checks for changes as well as which directories are checked for untracked files based on the path names given. An optimized way to tell git "all files have changed" is to return the filename `/`. The exit status determines whether git will use the data from the hook to limit its search. On error, it will fall back to verifying all files and folders. p4-changelist ~~~~~~~~~~~~~ This hook is invoked by `git-p4 submit`. The `p4-changelist` hook is executed after the changelist message has been edited by the user. It can be bypassed with the `--no-verify` option. It takes a single parameter, the name of the file that holds the proposed changelist text. Exiting with a non-zero status causes the command to abort. The hook is allowed to edit the changelist file and can be used to normalize the text into some project standard format. It can also be used to refuse the Submit after inspect the message file. Run `git-p4 submit --help` for details. p4-prepare-changelist ~~~~~~~~~~~~~~~~~~~~~ This hook is invoked by `git-p4 submit`. The `p4-prepare-changelist` hook is executed right after preparing the default changelist message and before the editor is started. It takes one parameter, the name of the file that contains the changelist text. Exiting with a non-zero status from the script will abort the process. The purpose of the hook is to edit the message file in place, and it is not suppressed by the `--no-verify` option. This hook is called even if `--prepare-p4-only` is set. Run `git-p4 submit --help` for details. p4-post-changelist ~~~~~~~~~~~~~~~~~~ This hook is invoked by `git-p4 submit`. The `p4-post-changelist` hook is invoked after the submit has successfully occurred in P4. It takes no parameters and is meant primarily for notification and cannot affect the outcome of the git p4 submit action. Run `git-p4 submit --help` for details. p4-pre-submit ~~~~~~~~~~~~~ This hook is invoked by `git-p4 submit`. It takes no parameters and nothing from standard input. Exiting with non-zero status from this script prevent `git-p4 submit` from launching. It can be bypassed with the `--no-verify` command line option. Run `git-p4 submit --help` for details. post-index-change ~~~~~~~~~~~~~~~~~ This hook is invoked when the index is written in read-cache.c do_write_locked_index. The first parameter passed to the hook is the indicator for the working directory being updated. "1" meaning working directory was updated or "0" when the working directory was not updated. The second parameter passed to the hook is the indicator for whether or not the index was updated and the skip-worktree bit could have changed. "1" meaning skip-worktree bits could have been updated and "0" meaning they were not. Only one parameter should be set to "1" when the hook runs. The hook running passing "1", "1" should not be possible. SEE ALSO -------- linkgit:git-hook[1] GIT --- Part of the linkgit:git[1] suite

This section describes various Git hooks, including fsmonitor-watchman, p4-changelist, p4-prepare-changelist, p4-post-changelist, p4-pre-submit, and post-index-change. These hooks are used to monitor file system changes, validate changelist messages, and perform other tasks such as normalizing text and refusing submits. Each hook has specific parameters and exit status behaviors that determine their effects on the Git workflow.