{
    "content": [
        {
            "type": "text",
            "text": "# githooks (info)\n\n## NAME\n\ngithooks - Hooks used by Git\n\n## SYNOPSIS\n\n$GITDIR/hooks/* (or `git config core.hooksPath`/*)\n\n## DESCRIPTION\n\nHooks are programs you can place in a hooks directory to trigger\nactions at certain points in git's execution. Hooks that don't have the\nexecutable bit set are ignored.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION**\n- **HOOKS**\n- **GIT**\n- **NOTES**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n"
        }
    ],
    "structuredContent": {
        "command": "githooks",
        "section": "",
        "mode": "info",
        "summary": "githooks - Hooks used by Git",
        "synopsis": "$GITDIR/hooks/* (or `git config core.hooksPath`/*)",
        "tldr_summary": null,
        "tldr_examples": [],
        "tldr_source": null,
        "flags": [],
        "examples": [],
        "see_also": [],
        "section_outline": [
            {
                "name": "NAME",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "SYNOPSIS",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "DESCRIPTION",
                "lines": 25,
                "subsections": []
            },
            {
                "name": "HOOKS",
                "lines": 576,
                "subsections": []
            },
            {
                "name": "GIT",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "NOTES",
                "lines": 4,
                "subsections": []
            }
        ],
        "sections": {
            "NAME": {
                "content": "githooks - Hooks used by Git\n",
                "subsections": []
            },
            "SYNOPSIS": {
                "content": "$GITDIR/hooks/* (or `git config core.hooksPath`/*)\n",
                "subsections": []
            },
            "DESCRIPTION": {
                "content": "Hooks are programs you can place in a hooks directory to trigger\nactions at certain points in git's execution. Hooks that don't have the\nexecutable bit set are ignored.\n\nBy default the hooks directory is $GITDIR/hooks, but that can be\nchanged via the core.hooksPath configuration variable (see git-\nconfig(1)).\n\nBefore Git invokes a hook, it changes its working directory to either\n$GITDIR in a bare repository or the root of the working tree in a\nnon-bare repository. An exception are hooks triggered during a push\n(pre-receive, update, post-receive, post-update, push-to-checkout)\nwhich are always executed in $GITDIR.\n\nHooks can get their arguments via the environment, command-line\narguments, and stdin. See the documentation for each hook below for\ndetails.\n\ngit init may copy hooks to the new repository, depending on its\nconfiguration. See the \"TEMPLATE DIRECTORY\" section in git-init(1) for\ndetails. When the rest of this document refers to \"default hooks\" it's\ntalking about the default template shipped with Git.\n\nThe currently supported hooks are described below.\n",
                "subsections": []
            },
            "HOOKS": {
                "content": "applypatch-msg\nThis hook is invoked by git-am(1). It takes a single parameter, the\nname of the file that holds the proposed commit log message. Exiting\nwith a non-zero status causes git am to abort before applying the\npatch.\n\nThe hook is allowed to edit the message file in place, and can be used\nto normalize the message into some project standard format. It can also\nbe used to refuse the commit after inspecting the message file.\n\nThe default applypatch-msg hook, when enabled, runs the commit-msg\nhook, if the latter is enabled.\n\npre-applypatch\nThis hook is invoked by git-am(1). It takes no parameter, and is\ninvoked after the patch is applied, but before a commit is made.\n\nIf it exits with non-zero status, then the working tree will not be\ncommitted after applying the patch.\n\nIt can be used to inspect the current working tree and refuse to make a\ncommit if it does not pass certain test.\n\nThe default pre-applypatch hook, when enabled, runs the pre-commit\nhook, if the latter is enabled.\n\npost-applypatch\nThis hook is invoked by git-am(1). It takes no parameter, and is\ninvoked after the patch is applied and a commit is made.\n\nThis hook is meant primarily for notification, and cannot affect the\noutcome of git am.\n\npre-commit\nThis hook is invoked by git-commit(1), and can be bypassed with the\n--no-verify option. It takes no parameters, and is invoked before\nobtaining the proposed commit log message and making a commit. Exiting\nwith a non-zero status from this script causes the git commit command\nto abort before creating a commit.\n\nThe default pre-commit hook, when enabled, catches introduction of\nlines with trailing whitespaces and aborts the commit when such a line\nis found.\n\nAll the git commit hooks are invoked with the environment variable\nGITEDITOR=: if the command will not bring up an editor to modify the\ncommit message.\n\nThe default pre-commit hook, when enabled--and with the\nhooks.allownonascii config option unset or set to false--prevents the\nuse of non-ASCII filenames.\n\npre-merge-commit\nThis hook is invoked by git-merge(1), and can be bypassed with the\n--no-verify option. It takes no parameters, and is invoked after the\nmerge has been carried out successfully and before obtaining the\nproposed commit log message to make a commit. Exiting with a non-zero\nstatus from this script causes the git merge command to abort before\ncreating a commit.\n\nThe default pre-merge-commit hook, when enabled, runs the pre-commit\nhook, if the latter is enabled.\n\nThis hook is invoked with the environment variable GITEDITOR=: if the\ncommand will not bring up an editor to modify the commit message.\n\nIf the merge cannot be carried out automatically, the conflicts need to\nbe resolved and the result committed separately (see git-merge(1)). At\nthat point, this hook will not be executed, but the pre-commit hook\nwill, if it is enabled.\n\nprepare-commit-msg\nThis hook is invoked by git-commit(1) right after preparing the default\nlog message, and before the editor is started.\n\nIt takes one to three parameters. The first is the name of the file\nthat contains the commit log message. The second is the source of the\ncommit message, and can be: message (if a -m or -F option was given);\ntemplate (if a -t option was given or the configuration option\ncommit.template is set); merge (if the commit is a merge or a\n.git/MERGEMSG file exists); squash (if a .git/SQUASHMSG file exists);\nor commit, followed by a commit object name (if a -c, -C or --amend\noption was given).\n\nIf the exit status is non-zero, git commit will abort.\n\nThe purpose of the hook is to edit the message file in place, and it is\nnot suppressed by the --no-verify option. A non-zero exit means a\nfailure of the hook and aborts the commit. It should not be used as\nreplacement for pre-commit hook.\n\nThe sample prepare-commit-msg hook that comes with Git removes the help\nmessage found in the commented portion of the commit template.\n\ncommit-msg\nThis hook is invoked by git-commit(1) and git-merge(1), and can be\nbypassed with the --no-verify option. It takes a single parameter, the\nname of the file that holds the proposed commit log message. Exiting\nwith a non-zero status causes the command to abort.\n\nThe hook is allowed to edit the message file in place, and can be used\nto normalize the message into some project standard format. It can also\nbe used to refuse the commit after inspecting the message file.\n\nThe default commit-msg hook, when enabled, detects duplicate\nSigned-off-by trailers, and aborts the commit if one is found.\n\npost-commit\nThis hook is invoked by git-commit(1). It takes no parameters, and is\ninvoked after a commit is made.\n\nThis hook is meant primarily for notification, and cannot affect the\noutcome of git commit.\n\npre-rebase\nThis hook is called by git-rebase(1) and can be used to prevent a\nbranch from getting rebased. The hook may be called with one or two\nparameters. The first parameter is the upstream from which the series\nwas forked. The second parameter is the branch being rebased, and is\nnot set when rebasing the current branch.\n\npost-checkout\nThis hook is invoked when a git-checkout(1) or git-switch(1) is run\nafter having updated the worktree. The hook is given three parameters:\nthe ref of the previous HEAD, the ref of the new HEAD (which may or may\nnot have changed), and a flag indicating whether the checkout was a\nbranch checkout (changing branches, flag=1) or a file checkout\n(retrieving a file from the index, flag=0). This hook cannot affect the\noutcome of git switch or git checkout, other than that the hook's exit\nstatus becomes the exit status of these two commands.\n\nIt is also run after git-clone(1), unless the --no-checkout (-n) option\nis used. The first parameter given to the hook is the null-ref, the\nsecond the ref of the new HEAD and the flag is always 1. Likewise for\ngit worktree add unless --no-checkout is used.\n\nThis hook can be used to perform repository validity checks,\nauto-display differences from the previous HEAD if different, or set\nworking dir metadata properties.\n\npost-merge\nThis hook is invoked by git-merge(1), which happens when a git pull is\ndone on a local repository. The hook takes a single parameter, a status\nflag specifying whether or not the merge being done was a squash merge.\nThis hook cannot affect the outcome of git merge and is not executed,\nif the merge failed due to conflicts.\n\nThis hook can be used in conjunction with a corresponding pre-commit\nhook to save and restore any form of metadata associated with the\nworking tree (e.g.: permissions/ownership, ACLS, etc). See\ncontrib/hooks/setgitperms.perl for an example of how to do this.\n\npre-push\nThis hook is called by git-push(1) and can be used to prevent a push\nfrom taking place. The hook is called with two parameters which provide\nthe name and location of the destination remote, if a named remote is\nnot being used both values will be the same.\n\nInformation about what is to be pushed is provided on the hook's\nstandard input with lines of the form:\n\n<local ref> SP <local object name> SP <remote ref> SP <remote object name> LF\n\nFor instance, if the command git push origin master:foreign were run\nthe hook would receive a line like the following:\n\nrefs/heads/master 67890 refs/heads/foreign 12345\n\nalthough the full object name would be supplied. If the foreign ref\ndoes not yet exist the <remote object name> will be the all-zeroes\nobject name. If a ref is to be deleted, the <local ref> will be\nsupplied as (delete) and the <local object name> will be the all-zeroes\nobject name. If the local commit was specified by something other than\na name which could be expanded (such as HEAD~, or an object name) it\nwill be supplied as it was originally given.\n\nIf this hook exits with a non-zero status, git push will abort without\npushing anything. Information about why the push is rejected may be\nsent to the user by writing to standard error.\n\npre-receive\nThis hook is invoked by git-receive-pack(1) when it reacts to git push\nand updates reference(s) in its repository. Just before starting to\nupdate refs on the remote repository, the pre-receive hook is invoked.\nIts exit status determines the success or failure of the update.\n\nThis hook executes once for the receive operation. It takes no\narguments, but for each ref to be updated it receives on standard input\na line of the format:\n\n<old-value> SP <new-value> SP <ref-name> LF\n\nwhere <old-value> is the old object name stored in the ref, <new-value>\nis the new object name to be stored in the ref and <ref-name> is the\nfull name of the ref. When creating a new ref, <old-value> is the\nall-zeroes object name.\n\nIf the hook exits with non-zero status, none of the refs will be\nupdated. If the hook exits with zero, updating of individual refs can\nstill be prevented by the update hook.\n\nBoth standard output and standard error output are forwarded to git\nsend-pack on the other end, so you can simply echo messages for the\nuser.\n\nThe number of push options given on the command line of git push\n--push-option=... can be read from the environment variable\nGITPUSHOPTIONCOUNT, and the options themselves are found in\nGITPUSHOPTION0, GITPUSHOPTION1,... If it is negotiated to not use\nthe push options phase, the environment variables will not be set. If\nthe client selects to use push options, but doesn't transmit any, the\ncount variable will be set to zero, GITPUSHOPTIONCOUNT=0.\n\nSee the section on \"Quarantine Environment\" in git-receive-pack(1) for\nsome caveats.\n\nupdate\nThis hook is invoked by git-receive-pack(1) when it reacts to git push\nand updates reference(s) in its repository. Just before updating the\nref on the remote repository, the update hook is invoked. Its exit\nstatus determines the success or failure of the ref update.\n\nThe hook executes once for each ref to be updated, and takes three\nparameters:\n\no   the name of the ref being updated,\n\no   the old object name stored in the ref,\n\no   and the new object name to be stored in the ref.\n\nA zero exit from the update hook allows the ref to be updated. Exiting\nwith a non-zero status prevents git receive-pack from updating that\nref.\n\nThis hook can be used to prevent forced update on certain refs by\nmaking sure that the object name is a commit object that is a\ndescendant of the commit object named by the old object name. That is,\nto enforce a \"fast-forward only\" policy.\n\nIt could also be used to log the old..new status. However, it does not\nknow the entire set of branches, so it would end up firing one e-mail\nper ref when used naively, though. The post-receive hook is more suited\nto that.\n\nIn an environment that restricts the users' access only to git commands\nover the wire, this hook can be used to implement access control\nwithout relying on filesystem ownership and group membership. See git-\nshell(1) for how you might use the login shell to restrict the user's\naccess to only git commands.\n\nBoth standard output and standard error output are forwarded to git\nsend-pack on the other end, so you can simply echo messages for the\nuser.\n\nThe default update hook, when enabled--and with hooks.allowunannotated\nconfig option unset or set to false--prevents unannotated tags to be\npushed.\n\nproc-receive\nThis hook is invoked by git-receive-pack(1). If the server has set the\nmulti-valued config variable receive.procReceiveRefs, and the commands\nsent to receive-pack have matching reference names, these commands will\nbe executed by this hook, instead of by the internal executecommands()\nfunction. This hook is responsible for updating the relevant references\nand reporting the results back to receive-pack.\n\nThis hook executes once for the receive operation. It takes no\narguments, but uses a pkt-line format protocol to communicate with\nreceive-pack to read commands, push-options and send results. In the\nfollowing example for the protocol, the letter S stands for\nreceive-pack and the letter H stands for this hook.\n\n# Version and features negotiation.\nS: PKT-LINE(version=1\\0push-options atomic...)\nS: flush-pkt\nH: PKT-LINE(version=1\\0push-options...)\nH: flush-pkt\n\n# Send commands from server to the hook.\nS: PKT-LINE(<old-oid> <new-oid> <ref>)\nS: ... ...\nS: flush-pkt\n# Send push-options only if the 'push-options' feature is enabled.\nS: PKT-LINE(push-option)\nS: ... ...\nS: flush-pkt\n\n# Receive result from the hook.\n# OK, run this command successfully.\nH: PKT-LINE(ok <ref>)\n# NO, I reject it.\nH: PKT-LINE(ng <ref> <reason>)\n# Fall through, let 'receive-pack' to execute it.\nH: PKT-LINE(ok <ref>)\nH: PKT-LINE(option fall-through)\n# OK, but has an alternate reference.  The alternate reference name\n# and other status can be given in option directives.\nH: PKT-LINE(ok <ref>)\nH: PKT-LINE(option refname <refname>)\nH: PKT-LINE(option old-oid <old-oid>)\nH: PKT-LINE(option new-oid <new-oid>)\nH: PKT-LINE(option forced-update)\nH: ... ...\nH: flush-pkt\n\nEach command for the proc-receive hook may point to a pseudo-reference\nand always has a zero-old as its old-oid, while the proc-receive hook\nmay update an alternate reference and the alternate reference may exist\nalready with a non-zero old-oid. For this case, this hook will use\n\"option\" directives to report extended attributes for the reference\ngiven by the leading \"ok\" directive.\n\nThe report of the commands of this hook should have the same order as\nthe input. The exit status of the proc-receive hook only determines the\nsuccess or failure of the group of commands sent to it, unless atomic\npush is in use.\n\npost-receive\nThis hook is invoked by git-receive-pack(1) when it reacts to git push\nand updates reference(s) in its repository. It executes on the remote\nrepository once after all the refs have been updated.\n\nThis hook executes once for the receive operation. It takes no\narguments, but gets the same information as the pre-receive hook does\non its standard input.\n\nThis hook does not affect the outcome of git receive-pack, as it is\ncalled after the real work is done.\n\nThis supersedes the post-update hook in that it gets both old and new\nvalues of all the refs in addition to their names.\n\nBoth standard output and standard error output are forwarded to git\nsend-pack on the other end, so you can simply echo messages for the\nuser.\n\nThe default post-receive hook is empty, but there is a sample script\npost-receive-email provided in the contrib/hooks directory in Git\ndistribution, which implements sending commit emails.\n\nThe number of push options given on the command line of git push\n--push-option=... can be read from the environment variable\nGITPUSHOPTIONCOUNT, and the options themselves are found in\nGITPUSHOPTION0, GITPUSHOPTION1,... If it is negotiated to not use\nthe push options phase, the environment variables will not be set. If\nthe client selects to use push options, but doesn't transmit any, the\ncount variable will be set to zero, GITPUSHOPTIONCOUNT=0.\n\npost-update\nThis hook is invoked by git-receive-pack(1) when it reacts to git push\nand updates reference(s) in its repository. It executes on the remote\nrepository once after all the refs have been updated.\n\nIt takes a variable number of parameters, each of which is the name of\nref that was actually updated.\n\nThis hook is meant primarily for notification, and cannot affect the\noutcome of git receive-pack.\n\nThe post-update hook can tell what are the heads that were pushed, but\nit does not know what their original and updated values are, so it is a\npoor place to do log old..new. The post-receive hook does get both\noriginal and updated values of the refs. You might consider it instead\nif you need them.\n\nWhen enabled, the default post-update hook runs git update-server-info\nto keep the information used by dumb transports (e.g., HTTP) up to\ndate. If you are publishing a Git repository that is accessible via\nHTTP, you should probably enable this hook.\n\nBoth standard output and standard error output are forwarded to git\nsend-pack on the other end, so you can simply echo messages for the\nuser.\n\nreference-transaction\nThis hook is invoked by any Git command that performs reference\nupdates. It executes whenever a reference transaction is prepared,\ncommitted or aborted and may thus get called multiple times. The hook\ndoes not cover symbolic references (but that may change in the future).\n\nThe hook takes exactly one argument, which is the current state the\ngiven reference transaction is in:\n\no   \"prepared\": All reference updates have been queued to the\ntransaction and references were locked on disk.\n\no   \"committed\": The reference transaction was committed and all\nreferences now have their respective new value.\n\no   \"aborted\": The reference transaction was aborted, no changes were\nperformed and the locks have been released.\n\nFor each reference update that was added to the transaction, the hook\nreceives on standard input a line of the format:\n\n<old-value> SP <new-value> SP <ref-name> LF\n\nwhere <old-value> is the old object name passed into the reference\ntransaction, <new-value> is the new object name to be stored in the ref\nand <ref-name> is the full name of the ref. When force updating the\nreference regardless of its current value or when the reference is to\nbe created anew, <old-value> is the all-zeroes object name. To\ndistinguish these cases, you can inspect the current value of\n<ref-name> via git rev-parse.\n\nThe exit status of the hook is ignored for any state except for the\n\"prepared\" state. In the \"prepared\" state, a non-zero exit status will\ncause the transaction to be aborted. The hook will not be called with\n\"aborted\" state in that case.\n\npush-to-checkout\nThis hook is invoked by git-receive-pack(1) when it reacts to git push\nand updates reference(s) in its repository, and when the push tries to\nupdate the branch that is currently checked out and the\nreceive.denyCurrentBranch configuration variable is set to\nupdateInstead. Such a push by default is refused if the working tree\nand the index of the remote repository has any difference from the\ncurrently checked out commit; when both the working tree and the index\nmatch the current commit, they are updated to match the newly pushed\ntip of the branch. This hook is to be used to override the default\nbehaviour.\n\nThe hook receives the commit with which the tip of the current branch\nis going to be updated. It can exit with a non-zero status to refuse\nthe push (when it does so, it must not modify the index or the working\ntree). Or it can make any necessary changes to the working tree and to\nthe index to bring them to the desired state when the tip of the\ncurrent branch is updated to the new commit, and exit with a zero\nstatus.\n\nFor example, the hook can simply run git read-tree -u -m HEAD \"$1\" in\norder to emulate git fetch that is run in the reverse direction with\ngit push, as the two-tree form of git read-tree -u -m is essentially\nthe same as git switch or git checkout that switches branches while\nkeeping the local changes in the working tree that do not interfere\nwith the difference between the branches.\n\npre-auto-gc\nThis hook is invoked by git gc --auto (see git-gc(1)). It takes no\nparameter, and exiting with non-zero status from this script causes the\ngit gc --auto to abort.\n\npost-rewrite\nThis hook is invoked by commands that rewrite commits (git-commit(1)\nwhen called with --amend and git-rebase(1); however, full-history\n(re)writing tools like git-fast-import(1) or git-filter-repo[1]\ntypically do not call it!). Its first argument denotes the command it\nwas invoked by: currently one of amend or rebase. Further\ncommand-dependent arguments may be passed in the future.\n\nThe hook receives a list of the rewritten commits on stdin, in the\nformat\n\n<old-object-name> SP <new-object-name> [ SP <extra-info> ] LF\n\nThe extra-info is again command-dependent. If it is empty, the\npreceding SP is also omitted. Currently, no commands pass any\nextra-info.\n\nThe hook always runs after the automatic note copying (see\n\"notes.rewrite.<command>\" in git-config(1)) has happened, and thus has\naccess to these notes.\n\nThe following command-specific comments apply:\n\nrebase\nFor the squash and fixup operation, all commits that were squashed\nare listed as being rewritten to the squashed commit. This means\nthat there will be several lines sharing the same new-object-name.\n\nThe commits are guaranteed to be listed in the order that they were\nprocessed by rebase.\n\nsendemail-validate\nThis hook is invoked by git-send-email(1). It takes a single parameter,\nthe name of the file that holds the e-mail to be sent. Exiting with a\nnon-zero status causes git send-email to abort before sending any\ne-mails.\n\nfsmonitor-watchman\nThis hook is invoked when the configuration option core.fsmonitor is\nset to .git/hooks/fsmonitor-watchman or .git/hooks/fsmonitor-watchmanv2\ndepending on the version of the hook to use.\n\nVersion 1 takes two arguments, a version (1) and the time in elapsed\nnanoseconds since midnight, January 1, 1970.\n\nVersion 2 takes two arguments, a version (2) and a token that is used\nfor identifying changes since the token. For watchman this would be a\nclock id. This version must output to stdout the new token followed by\na NUL before the list of files.\n\nThe hook should output to stdout the list of all files in the working\ndirectory that may have changed since the requested time. The logic\nshould be inclusive so that it does not miss any potential changes. The\npaths should be relative to the root of the working directory and be\nseparated by a single NUL.\n\nIt is OK to include files which have not actually changed. All changes\nincluding newly-created and deleted files should be included. When\nfiles are renamed, both the old and the new name should be included.\n\nGit will limit what files it checks for changes as well as which\ndirectories are checked for untracked files based on the path names\ngiven.\n\nAn optimized way to tell git \"all files have changed\" is to return the\nfilename /.\n\nThe exit status determines whether git will use the data from the hook\nto limit its search. On error, it will fall back to verifying all files\nand folders.\n\np4-changelist\nThis hook is invoked by git-p4 submit.\n\nThe p4-changelist hook is executed after the changelist message has\nbeen edited by the user. It can be bypassed with the --no-verify\noption. It takes a single parameter, the name of the file that holds\nthe proposed changelist text. Exiting with a non-zero status causes the\ncommand to abort.\n\nThe hook is allowed to edit the changelist file and can be used to\nnormalize the text into some project standard format. It can also be\nused to refuse the Submit after inspect the message file.\n\nRun git-p4 submit --help for details.\n\np4-prepare-changelist\nThis hook is invoked by git-p4 submit.\n\nThe p4-prepare-changelist hook is executed right after preparing the\ndefault changelist message and before the editor is started. It takes\none parameter, the name of the file that contains the changelist text.\nExiting with a non-zero status from the script will abort the process.\n\nThe purpose of the hook is to edit the message file in place, and it is\nnot suppressed by the --no-verify option. This hook is called even if\n--prepare-p4-only is set.\n\nRun git-p4 submit --help for details.\n\np4-post-changelist\nThis hook is invoked by git-p4 submit.\n\nThe p4-post-changelist hook is invoked after the submit has\nsuccessfully occurred in P4. It takes no parameters and is meant\nprimarily for notification and cannot affect the outcome of the git p4\nsubmit action.\n\nRun git-p4 submit --help for details.\n\np4-pre-submit\nThis hook is invoked by git-p4 submit. It takes no parameters and\nnothing from standard input. Exiting with non-zero status from this\nscript prevent git-p4 submit from launching. It can be bypassed with\nthe --no-verify command line option. Run git-p4 submit --help for\ndetails.\n\npost-index-change\nThis hook is invoked when the index is written in read-cache.c\ndowritelockedindex.\n\nThe first parameter passed to the hook is the indicator for the working\ndirectory being updated. \"1\" meaning working directory was updated or\n\"0\" when the working directory was not updated.\n\nThe second parameter passed to the hook is the indicator for whether or\nnot the index was updated and the skip-worktree bit could have changed.\n\"1\" meaning skip-worktree bits could have been updated and \"0\" meaning\nthey were not.\n\nOnly one parameter should be set to \"1\" when the hook runs. The hook\nrunning passing \"1\", \"1\" should not be possible.\n",
                "subsections": []
            },
            "GIT": {
                "content": "Part of the git(1) suite\n",
                "subsections": []
            },
            "NOTES": {
                "content": "1. git-filter-repo\nhttps://github.com/newren/git-filter-repo\n\nGit 2.34.1                        02/26/2026                       GITHOOKS(5)",
                "subsections": []
            }
        }
    }
}