summaryrefslogtreecommitdiff
path: root/Documentation/githooks.txt
AgeCommit message (Collapse)AuthorFilesLines
2020-11-11Merge branch 'mc/typofix'Libravatar Junio C Hamano1-1/+1
Docfix. * mc/typofix: doc: fixing two trivial typos in Documentation/
2020-11-05doc: fixing two trivial typos in Documentation/Libravatar Marlon Rac Cambasis1-1/+1
Fix misspelled "specified" and "occurred" in documentation and comments. Signed-off-by: Marlon Rac Cambasis <marlonrc08@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20Documentation: stylistically normalize references to Signed-off-by:Libravatar Bradley M. Kuhn1-1/+1
Ted reported an old typo in the git-commit.txt and merge-options.txt. Namely, the phrase "Signed-off-by line" was used without either a definite nor indefinite article. Upon examination, it seems that the documentation (including items in Documentation/, but also option help strings) have been quite inconsistent on usage when referring to `Signed-off-by`. First, very few places used a definite or indefinite article with the phrase "Signed-off-by line", but that was the initial typo that led to this investigation. So, normalize using either an indefinite or definite article consistently. The original phrasing, in Commit 3f971fc425b (Documentation updates, 2005-08-14), is "Add Signed-off-by line". Commit 6f855371a53 (Add --signoff, --check, and long option-names. 2005-12-09) switched to using "Add `Signed-off-by:` line", but didn't normalize the former commit to match. Later commits seem to have cut and pasted from one or the other, which is likely how the usage became so inconsistent. Junio stated on the git mailing list in <xmqqy2k1dfoh.fsf@gitster.c.googlers.com> a preference to leave off the colon. Thus, prefer `Signed-off-by` (with backticks) for the documentation files and Signed-off-by (without backticks) for option help strings. Additionally, Junio argued that "trailer" is now the standard term to refer to `Signed-off-by`, saying that "becomes plenty clear that we are not talking about any random line in the log message". As such, prefer "trailer" over "line" anywhere the former word fits. However, leave alone those few places in documentation that use Signed-off-by to refer to the process (rather than the specific trailer), or in places where mail headers are generally discussed in comparison with Signed-off-by. Reported-by: "Theodore Y. Ts'o" <tytso@mit.edu> Signed-off-by: Bradley M. Kuhn <bkuhn@sfconservancy.org> Acked-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-25Merge branch 'jx/proc-receive-hook'Libravatar Junio C Hamano1-0/+62
"git receive-pack" that accepts requests by "git push" learned to outsource most of the ref updates to the new "proc-receive" hook. * jx/proc-receive-hook: doc: add documentation for the proc-receive hook transport: parse report options for tracking refs t5411: test updates of remote-tracking branches receive-pack: new config receive.procReceiveRefs doc: add document for capability report-status-v2 New capability "report-status-v2" for git-push receive-pack: feed report options to post-receive receive-pack: add new proc-receive hook t5411: add basic test cases for proc-receive hook transport: not report a non-head push as a branch
2020-08-27doc: clarify how exit status of post-checkout hook is usedLibravatar Junio C Hamano1-1/+3
Because the hook runs after the main checkout operation finishes, it cannot affect what branch will be the current branch, what paths are updated in the working tree, etc., which was described as "cannot affect the outcome of 'checkout'". However, the exit status of the hook is used as the exit status of the 'checkout' command and is observable by anybody who spawned the 'checkout', which was missing from the documentation. Fix this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27doc: add documentation for the proc-receive hookLibravatar Jiang Xin1-0/+62
"git receive-pack" that accepts requests by "git push" learned to outsource some of the ref updates to the new "proc-receive" hook. Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-24githooks.txt: use correct "reference-transaction" hook nameLibravatar Bojun Chen1-2/+2
The "reference transaction" hook was introduced in commit 6754159767 (refs: implement reference transaction hook, 2020-06-19). The name of the hook is declared as "reference-transaction" in "refs.c" and testcases, but the name declared in "githooks.txt" is different. Signed-off-by: Bojun Chen <bojun.cbj@alibaba-inc.com> Reviewed-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19refs: implement reference transaction hookLibravatar Patrick Steinhardt1-0/+29
The low-level reference transactions used to update references are currently completely opaque to the user. While certainly desirable in most usecases, there are some which might want to hook into the transaction to observe all queued reference updates as well as observing the abortion or commit of a prepared transaction. One such usecase would be to have a set of replicas of a given Git repository, where we perform Git operations on all of the repositories at once and expect the outcome to be the same in all of them. While there exist hooks already for a certain subset of Git commands that could be used to implement a voting mechanism for this, many others currently don't have any mechanism for this. The above scenario is the motivation for the new "reference-transaction" hook that reaches directly into Git's reference transaction mechanism. The hook receives as parameter the current state the transaction was moved to ("prepared", "committed" or "aborted") and gets via its standard input all queued reference updates. While the exit code gets ignored in the "committed" and "aborted" states, a non-zero exit code in the "prepared" state will cause the transaction to be aborted prematurely. Given the usecase described above, a voting mechanism can now be implemented via this hook: as soon as it gets called, it will take all of stdin and use it to cast a vote to a central service. When all replicas of the repository agree, the hook will exit with zero, otherwise it will abort the transaction by returning non-zero. The most important upside is that this will catch _all_ commands writing references at once, allowing to implement strong consistency for reference updates via a single mechanism. In order to test the impact on the case where we don't have any "reference-transaction" hook installed in the repository, this commit introduce two new performance tests for git-update-refs(1). Run against an empty repository, it produces the following results: Test origin/master HEAD -------------------------------------------------------------------- 1400.2: update-ref 2.70(2.10+0.71) 2.71(2.10+0.73) +0.4% 1400.3: update-ref --stdin 0.21(0.09+0.11) 0.21(0.07+0.14) +0.0% The performance test p1400.2 creates, updates and deletes a branch a thousand times, thus averaging runtime of git-update-refs over 3000 invocations. p1400.3 instead calls `git-update-refs --stdin` three times and queues a thousand creations, updates and deletes respectively. As expected, p1400.3 consistently shows no noticeable impact, as for each batch of updates there's a single call to access(3P) for the negative hook lookup. On the other hand, for p1400.2, one can see an impact caused by this patchset. But doing five runs of the performance tests where each one was run with GIT_PERF_REPEAT_COUNT=10, the overhead ranged from -1.5% to +1.1%. These inconsistent performance numbers can be explained by the overhead of spawning 3000 processes. This shows that the overhead of assembling the hook path and executing access(3P) once to check if it's there is mostly outweighed by the operating system's overhead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-22Merge branch 'bk/p4-pre-edit-changelist'Libravatar Junio C Hamano1-1/+50
"git p4" learned four new hooks and also "--no-verify" option to bypass them (and the existing "p4-pre-submit" hook). * bk/p4-pre-edit-changelist: git-p4: add RCS keyword status message git-p4: add p4 submit hooks git-p4: restructure code in submit git-p4: add --no-verify option git-p4: add p4-pre-submit exit text git-p4: create new function run_git_hook git-p4: rewrite prompt to be Windows compatible
2020-02-14git-p4: add p4 submit hooksLibravatar Ben Keene1-0/+46
The git command "commit" supports a number of hooks that support changing the behavior of the commit command. The git-p4.py program only has one existing hook, "p4-pre-submit". This command occurs early in the process. There are no hooks in the process flow for modifying the P4 changelist text programmatically. Adds 3 new hooks to git-p4.py to the submit option. The new hooks are: * p4-prepare-changelist - Execute this hook after the changelist file has been created. The hook will be executed even if the --prepare-p4-only option is set. This hook ignores the --no-verify option in keeping with the existing behavior of git commit. * p4-changelist - Execute this hook after the user has edited the changelist. Do not execute this hook if the user has selected the --prepare-p4-only option. This hook will honor the --no-verify, following the conventions of git commit. * p4-post-changelist - Execute this hook after the P4 submission process has completed successfully. This hook takes no parameters and is executed regardless of the --no-verify option. It's return value will not be checked. The calls to the new hooks: p4-prepare-changelist, p4-changelist, and p4-post-changelist should all be called inside the try-finally block. Signed-off-by: Ben Keene <seraphire@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-11git-p4: add --no-verify optionLibravatar Ben Keene1-1/+4
Add new command line option --no-verify: Add a new command line option "--no-verify" to the Submit command of git-p4.py. This option will function in the spirit of the existing --no-verify command line option found in git commit. It will cause the P4 Submit function to ignore the existing p4-pre-submit. Change the execution of the existing trigger p4-pre-submit to honor the --no-verify option. Before exiting on failure of this hook, display text to the user explaining which hook has failed and the impact of using the --no-verify option. Change the call of the p4-pre-submit hook to use the new run_git_hook function. This is in preparation of additional hooks to be added. Signed-off-by: Ben Keene <seraphire@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-23fsmonitor: update documentation for hook version and watchman hooksLibravatar Kevin Willford1-3/+10
A new config value for core.fsmonitorHookVersion was added to be able to force the version of the fsmonitor hook. Possible values are 1 or 2. When this is not set the code will use a value of -1 and attempt to use version 2 of the hook first and if that fails will attempt version 1. Signed-off-by: Kevin Willford <Kevin.Willford@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-30Merge branch 'en/filter-branch-deprecation'Libravatar Junio C Hamano1-4/+6
Start discouraging the use of "git filter-branch". * en/filter-branch-deprecation: t9902: use a non-deprecated command for testing Recommend git-filter-repo instead of git-filter-branch t6006: simplify, fix, and optimize empty message test
2019-09-05Recommend git-filter-repo instead of git-filter-branchLibravatar Elijah Newren1-4/+6
filter-branch suffers from a deluge of disguised dangers that disfigure history rewrites (i.e. deviate from the deliberate changes). Many of these problems are unobtrusive and can easily go undiscovered until the new repository is in use. This can result in problems ranging from an even messier history than what led folks to filter-branch in the first place, to data loss or corruption. These issues cannot be backward compatibly fixed, so add a warning to both filter-branch and its manpage recommending that another tool (such as filter-repo) be used instead. Also, update other manpages that referenced filter-branch. Several of these needed updates even if we could continue recommending filter-branch, either due to implying that something was unique to filter-branch when it applied more generally to all history rewriting tools (e.g. BFG, reposurgeon, fast-import, filter-repo), or because something about filter-branch was used as an example despite other more commonly known examples now existing. Reword these sections to fix these issues and to avoid recommending filter-branch. Finally, remove the section explaining BFG Repo Cleaner as an alternative to filter-branch. I feel somewhat bad about this, especially since I feel like I learned so much from BFG that I put to good use in filter-repo (which is much more than I can say for filter-branch), but keeping that section presented a few problems: * In order to recommend that people quit using filter-branch, we need to provide them a recomendation for something else to use that can handle all the same types of rewrites. To my knowledge, filter-repo is the only such tool. So it needs to be mentioned. * I don't want to give conflicting recommendations to users * If we recommend two tools, we shouldn't expect users to learn both and pick which one to use; we should explain which problems one can solve that the other can't or when one is much faster than the other. * BFG and filter-repo have similar performance * All filtering types that BFG can do, filter-repo can also do. In fact, filter-repo comes with a reimplementation of BFG named bfg-ish which provides the same user-interface as BFG but with several bugfixes and new features that are hard to implement in BFG due to its technical underpinnings. While I could still mention both tools, it seems like I would need to provide some kind of comparison and I would ultimately just say that filter-repo can do everything BFG can, so ultimately it seems that it is just better to remove that section altogether. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-07merge: --no-verify to bypass pre-merge-commit hookLibravatar Michael J Gruber1-1/+2
Analogous to commit, introduce a '--no-verify' option which bypasses the pre-merge-commit hook. The shorthand '-n' is taken by '--no-stat' already. [js: * reworded commit message to reflect current state of --no-stat flag and new hook name * fixed flag documentation to reflect new hook name * cleaned up trailing whitespace * squashed test changes from the original series' patch 4/4 * modified tests to follow pattern from this series' patch 1/4 * added a test case for --no-verify with non-executable hook * when testing that the merge hook did not run, make sure we actually have a merge to perform (by resetting the "side" branch to its original state). ] Improved-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-07git-merge: honor pre-merge-commit hookLibravatar Michael J Gruber1-0/+21
git-merge does not honor the pre-commit hook when doing automatic merge commits, and for compatibility reasons this is going to stay. Introduce a pre-merge-commit hook which is called for an automatic merge commit just like pre-commit is called for a non-automatic merge commit (or any other commit). [js: * renamed hook from "pre-merge" to "pre-merge-commit" * only discard the index if the hook is actually present * expanded githooks documentation entry * clarified that hook should write messages to stderr * squashed test changes from the original series' patch 4/4 * modified tests to follow new pattern from this series' patch 1/4 * added a test case for non-executable merge hooks * added a test case for failed merges * when testing that the merge hook did not run, make sure we actually have a merge to perform (by resetting the "side" branch to its original state). * reworded commit message ] Improved-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-09Merge branch 'nd/switch-and-restore'Libravatar Junio C Hamano1-3/+5
Two new commands "git switch" and "git restore" are introduced to split "checking out a branch to work on advancing its history" and "checking out paths out of the index and/or a tree-ish to work on advancing the current history" out of the single "git checkout" command. * nd/switch-and-restore: (46 commits) completion: disable dwim on "git switch -d" switch: allow to switch in the middle of bisect t2027: use test_must_be_empty Declare both git-switch and git-restore experimental help: move git-diff and git-reset to different groups doc: promote "git restore" user-manual.txt: prefer 'merge --abort' over 'reset --hard' completion: support restore t: add tests for restore restore: support --patch restore: replace --force with --ignore-unmerged restore: default to --source=HEAD when only --staged is specified restore: reject invalid combinations with --staged restore: add --worktree and --staged checkout: factor out worktree checkout code restore: disable overlay mode by default restore: make pathspec mandatory restore: take tree-ish from --source option instead checkout: split part of it to new command 'restore' doc: promote "git switch" ...
2019-04-25Merge branch 'bp/post-index-change-hook'Libravatar Junio C Hamano1-0/+18
A new hook "post-index-change" is called when the on-disk index file changes, which can help e.g. a virtualized working tree implementation. * bp/post-index-change-hook: read-cache: add post-index-change hook
2019-04-02checkout: split part of it to new command 'switch'Libravatar Nguyễn Thái Ngọc Duy1-3/+5
"git checkout" doing too many things is a source of confusion for many users (and it even bites old timers sometimes). To remedy that, the command will be split into two new ones: switch and restore. The good old "git checkout" command is still here and will be until all (or most of users) are sick of it. See the new man page for the final design of switch. The actual implementation though is still pretty much the same as "git checkout" and not completely aligned with the man page. Following patches will adjust their behavior to match the man page. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-21mention use of "hooks.allownonascii" in "man githooks"Libravatar Robert P. J. Day1-0/+4
The default pre-commit script checks the config variable "hooks.allownonascii" to determine whether to allow non-ASCII file names -- mention this in "man githooks", just as the section on "update" mentions the use of "hooks.allowunannotated". Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-15read-cache: add post-index-change hookLibravatar Ben Peart1-0/+18
Add a post-index-change hook that is invoked after the index is written in do_write_locked_index(). This hook is meant primarily for notification, and cannot affect the outcome of git commands that trigger the index write. The hook is passed a flag to indicate whether the working directory was updated or not and a flag indicating if a skip-worktree bit could have changed. These flags enable the hook to optimize its response to the index change notification. Signed-off-by: Ben Peart <benpeart@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-01git-p4: add the `p4-pre-submit` hookLibravatar Chen Bin1-0/+7
The `p4-pre-submit` hook is executed before git-p4 submits code. If the hook exits with non-zero value, submit process not start. Signed-off-by: Chen Bin <chenbin.sh@gmail.com> Reviewed-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-06doc: improve formatting in githooks.txtLibravatar Andreas Heiduk1-57/+58
Typeset commands and similar things with as `git foo` instead of 'git foo' or 'git-foo' and add linkgit to the commands which run the hooks. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Reviewed-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-27Merge branch 'es/worktree-checkout-hook'Libravatar Junio C Hamano1-1/+2
"git worktree add" learned to run the post-checkout hook, just like "git checkout" does, after the initial checkout. * es/worktree-checkout-hook: worktree: invoke post-checkout hook (unless --no-checkout)
2017-12-13Merge branch 'jc/receive-pack-hook-doc'Libravatar Junio C Hamano1-10/+10
Doc update. * jc/receive-pack-hook-doc: hooks doc: clarify when receive-pack invokes its hooks
2017-12-07worktree: invoke post-checkout hook (unless --no-checkout)Libravatar Eric Sunshine1-1/+2
git-clone and git-checkout both invoke the post-checkout hook following a successful checkout, yet git-worktree neglects to do so even though it too "checks out" the worktree. Fix this oversight. Implementation note: The newly-created worktree may reference a branch or be detached. In the latter case, a commit lookup is performed, though the result is used only in a boolean sense to (a) determine if the commit actually exists, and (b) assign either the branch name or commit ID to HEAD. Since the post-commit hook needs to know the ID of the checked-out commit, the lookup now needs to be done in all cases, rather than only when detached. Consequently, a new boolean is needed to handle (b) since the lookup result itself can no longer perform that role. Reported-by: Matthew K Gumbel <matthew.k.gumbel@intel.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-24hooks doc: clarify when receive-pack invokes its hooksLibravatar Junio C Hamano1-10/+10
The text meant to say that receive-pack runs these hooks, and only because receive-pack is not a command the end users use every day (ever), as an explanation also meantioned that it is run in response to 'git push', which is an end-user facing command readers hopefully know about. This unfortunately gave an incorrect impression that 'git push' always result in the hook to run. If the refs push wanted to update all already had the desired value, these hooks are not run. Explicitly mention "... and updates reference(s)" as a precondition to avoid this confusion. Helped-by: Christoph Michelbach <michelbach94@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-21Merge branch 'bp/fsmonitor'Libravatar Junio C Hamano1-0/+28
We learned to talk to watchman to speed up "git status" and other operations that need to see which paths have been modified. * bp/fsmonitor: fsmonitor: preserve utf8 filenames in fsmonitor-watchman log fsmonitor: read entirety of watchman output fsmonitor: MINGW support for watchman integration fsmonitor: add a performance test fsmonitor: add a sample integration script for Watchman fsmonitor: add test cases for fsmonitor extension split-index: disable the fsmonitor extension when running the split index test fsmonitor: add a test tool to dump the index extension update-index: add fsmonitor support to update-index ls-files: Add support in ls-files to display the fsmonitor valid bit fsmonitor: add documentation for the fsmonitor extension. fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files. update-index: add a new --force-write-index option preload-index: add override to enable testing preload-index bswap: add 64 bit endianness helper get_be64
2017-10-01fsmonitor: add documentation for the fsmonitor extension.Libravatar Ben Peart1-0/+28
This includes the core.fsmonitor setting, the fsmonitor integration hook, and the fsmonitor index extension. Also add documentation for the new fsmonitor options to ls-files and update-index. Signed-off-by: Ben Peart <benpeart@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-29Merge branch 'sb/merge-commit-msg-hook'Libravatar Junio C Hamano1-5/+4
As "git commit" to conclude a conflicted "git merge" honors the commit-msg hook, "git merge" that records a merge commit that cleanly auto-merges should, but it didn't. * sb/merge-commit-msg-hook (2017-09-22) 1 commit (merged to 'next' on 2017-09-25 at 096e0502a8) + Documentation/githooks: mention merge in commit-msg hook Add documentation for a topic that has recently graduated to the 'master' branch. * sb/merge-commit-msg-hook: Documentation/githooks: mention merge in commit-msg hook
2017-09-22Documentation/githooks: mention merge in commit-msg hookLibravatar Stefan Beller1-5/+4
The commit-msg hook is invoked by both commit and merge now. Reported-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-10Merge branch 'ma/up-to-date'Libravatar Junio C Hamano1-1/+1
Message and doc updates. * ma/up-to-date: treewide: correct several "up-to-date" to "up to date" Documentation/user-manual: update outdated example output
2017-08-23treewide: correct several "up-to-date" to "up to date"Libravatar Martin Ågren1-1/+1
Follow the Oxford style, which says to use "up-to-date" before the noun, but "up to date" after it. Don't change plumbing (specifically send-pack.c, but transport.c (git push) also has the same string). This was produced by grepping for "up-to-date" and "up to date". It turned out we only had to edit in one direction, removing the hyphens. Fix a typo in Documentation/git-diff-index.txt while we're there. Reported-by: Jeffrey Manian <jeffrey.manian@gmail.com> Reported-by: STEVEN WHITE <stevencharleswhitevoices@gmail.com> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-12hook: add a simple first exampleLibravatar Kaartic Sivaraam1-0/+3
Add a simple example that replaces an outdated example that was removed. This ensures that there's at the least a simple example that illustrates what could be done using the hook just by enabling it. Also, update the documentation. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-12hook: cleanup scriptLibravatar Kaartic Sivaraam1-3/+0
Prepare the 'preare-commit-msg' sample script for upcoming changes. Preparation includes removal of an example that has outlived it's purpose. The example is the one that comments the "Conflicts:" part of a merge commit message. It isn't relevant anymore as it's done by default since 261f315b ("merge & sequencer: turn "Conflicts:" hint into a comment", 2014-08-28). Further update the relevant comments from the sample script and update the documentation. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-16send-email: support validate hookLibravatar Jonathan Tan1-0/+8
Currently, send-email has support for rudimentary e-mail validation. Allow the user to add support for more validation by providing a sendemail-validate hook. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-04Merge branch 'sr/hooks-cwd-doc'Libravatar Junio C Hamano1-2/+4
* sr/hooks-cwd-doc: githooks.txt: clarify push hooks are always executed in $GIT_DIR
2017-05-01githooks.txt: clarify push hooks are always executed in $GIT_DIRLibravatar Simon Ruderich1-2/+4
Listing the specific hooks might feel verbose but without it the reader is left to wonder which hooks are triggered during the push. Something which is not immediately obvious when only trying to find out where the hook is executed. Signed-off-by: Simon Ruderich <simon@ruderich.org> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-16receive-pack: document user-visible quarantine effectsLibravatar Jeff King1-0/+3
Commit 722ff7f87 (receive-pack: quarantine objects until pre-receive accepts, 2016-10-03) changed the underlying details of how we take in objects. This is mostly transparent to the user, but there are a few things they might notice. Let's document them. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14push options: {pre,post}-receive hook learns about push optionsLibravatar Stefan Beller1-0/+18
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted option. The code is not executed as the push options are set to NULL, nor is the new capability advertised. There was some discussion back and forth how to present these push options to the user as there are some ways to do it: Keep all options in one environment variable ============================================ + easiest way to implement in Git - This would make things hard to parse correctly in the hook. Put the options in files instead, filenames are in GIT_PUSH_OPTION_FILES ====================================== + After a discussion about environment variables and shells, we may not want to put user data into an environment variable (see [1] for example). + We could transmit binaries, i.e. we're not bound to C strings as we are when using environment variables to the user. + Maybe easier to parse than constructing environment variable names GIT_PUSH_OPTION_{0,1,..} yourself - cleanup of the temporary files is hard to do reliably - we have race conditions with multiple clients pushing, hence we'd need to use mkstemp. That's not too bad, but still. Use environment variables, but restrict to key/value pairs ========================================================== (When the user pushes a push option `foo=bar`, we'd GIT_PUSH_OPTION_foo=bar) + very easy to parse for a simple model of push options - it's not sufficient for more elaborate models, e.g. it doesn't allow doubles (e.g. cc=reviewer@email) Present the options in different environment variables ====================================================== (This is implemented) * harder to parse as a user, but we have a sample hook for that. - doesn't allow binary files + allows the same option twice, i.e. is not restrictive about options, except for binary files. + doesn't clutter a remote directory with (possibly stale) temporary files As we first want to focus on getting simple strings to work reliably, we go with the last option for now. If we want to do transmission of binaries later, we can just attach a 'side-channel', e.g. "any push option that contains a '\0' is put into a file instead of the environment variable and we'd have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..} environment variables". [1] 'Shellshock' https://lwn.net/Articles/614218/ Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-04hooks: allow customizing where the hook directory isLibravatar Ævar Arnfjörð Bjarmason1-4/+8
Change the hardcoded lookup for .git/hooks/* to optionally lookup in $(git config core.hooksPath)/* instead. This is essentially a more intrusive version of the git-init ability to specify hooks on init time via init templates. The difference between that facility and this feature is that this can be set up after the fact via e.g. ~/.gitconfig or /etc/gitconfig to apply for all your personal repositories, or all repositories on the system. I plan on using this on a centralized Git server where users can create arbitrary repositories under /gitroot, but I'd like to manage all the hooks that should be run centrally via a unified dispatch mechanism. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-04githooks.txt: minor improvements to the grammar & phrasingLibravatar Ævar Arnfjörð Bjarmason1-16/+16
Change: * Sentences that needed "the" or "a" to either add those or change them so they don't need them. * The little tangent about "You can use this to do X (if your project wants to do X)" can just be shortened to "if you want to do X". * s/parameter/parameters/ when the plural made more sense. Most of this goes all the way back to the initial introduction of hooks.txt in 6d35cc76 (Document hooks., 2005-09-02). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-04githooks.txt: amend dangerous advice about 'update' hook ACLLibravatar Ævar Arnfjörð Bjarmason1-3/+5
Any ACL you implement via an 'update' hook isn't actual access control if the user has login access to the machine running git, because they can trivially just build their own version of Git which doesn't run the hook. Change the documentation to take this dangerous edge case into account, and remove the mention of the advice originating on the mailing list, the users reading this don't care where the idea came up. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-04githooks.txt: improve the intro sectionLibravatar Ævar Arnfjörð Bjarmason1-12/+19
Change the documentation so that: * We don't talk about "little scripts". Hooks can be as big as you want, and don't have to be scripts, just call them "programs". * We note that we change the working directory before a hook is called, nothing documented this explicitly, but the current behavior is predictable. It helps a lot to know what directory these hooks will be executed from. * We don't make claims about the example hooks which may not be true depending on the configuration of 'init.templateDir'. Clarify that we're talking about the default settings of git-init in those cases, and move some of this documentation into git-init's documentation about the default templates. * We briefly note in the intro that hooks can get their arguments in various different ways, and that how exactly is described below for each hook. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-21Documentation: fix broken linkgit to git-configLibravatar Matthieu Moy1-1/+1
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-08receive-pack: support push-to-checkout hookLibravatar Junio C Hamano1-0/+30
When receive.denyCurrentBranch is set to updateInstead, a push that tries to update the branch that is currently checked out is accepted only when the index and the working tree exactly matches the currently checked out commit, in which case the index and the working tree are updated to match the pushed commit. Otherwise the push is refused. This hook can be used to customize this "push-to-deploy" logic. The hook receives the commit with which the tip of the current branch is going to be updated, and can decide what kind of local changes are acceptable and how to update the index and the working tree to match the updated tip of the current branch. For example, the hook can simply run `git read-tree -u -m HEAD "$1"` in order to emulate 'git fetch' that is run in the reverse direction with `git push`, as the two-tree form of `read-tree -u -m` is essentially the same as `git checkout` that switches branches while keeping the local changes in the working tree that do not interfere with the difference between the branches. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-04Documentation: typofixesLibravatar Thomas Ackermann1-1/+1
In addition to fixing trivial and obvious typos, be careful about the following points: - Spell ASCII, URL and CRC in ALL CAPS; - Spell Linux as Capitalized; - Do not omit periods in "i.e." and "e.g.". Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-05Documentation: fix typos in man pagesLibravatar Øystein Walle1-1/+1
Signed-off-by: Øystein Walle <oystwa@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15The name of the hash function is "SHA-1", not "SHA1"Libravatar Thomas Ackermann1-5/+5
Use "SHA-1" instead of "SHA1" whenever we talk about the hash function. When used as a programming symbol, we keep "SHA1". Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25Merge branch 'maint-1.8.1' into maintLibravatar Junio C Hamano1-3/+5
* maint-1.8.1: bundle: Add colons to list headings in "verify" bundle: Fix "verify" output if history is complete Documentation: filter-branch env-filter example git-filter-branch.txt: clarify ident variables usage git-compat-util.h: Provide missing netdb.h definitions describe: Document --match pattern format Documentation/githooks: Explain pre-rebase parameters update-index: list supported idx versions and their features diff-options: unconfuse description of --color read-cache.c: use INDEX_FORMAT_{LB,UB} in verify_hdr() index-format.txt: mention of v4 is missing in some places