aboutsummaryrefslogtreecommitdiff
path: root/Documentation/githooks.txt
Commit message (Collapse)AuthorAge
* docs: stop using asciidoc no-inline-literalJeff King2012-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation/githooks: post-rewrite-copy-notes never existedThomas Rast2011-01-10
| | | | | | | | | | | | | | | The documentation for the post-rewrite hook contains a paragraph from its early development, where the automatic notes copying facilities were not part of the series and thus this had to be a hook. Later versions of the series implemented notes copying as a core feature. Thus mentioning post-rewrite-copy-notes was never correct. As the other hooks do not have a "there is no default hook, but..." sentence unless they ship a sample hook in either templates or contrib, we simply remove the whole paragraph. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* notes: implement helpers needed for note copying during rewriteThomas Rast2010-03-12
| | | | | | | | | | | | | | Implement helper functions to load the rewriting config, and to actually copy the notes. Also document the config. Secondly, also implement an undocumented --for-rewrite=<cmd> option to 'git notes copy' which is used like --stdin, but also puts the configuration for <cmd> into effect. It will be needed to support the copying in git-rebase. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation: document post-rewrite hookThomas Rast2010-03-12
| | | | | | | | | | | | | | | This defines the behaviour of the post-rewrite hook support, which will be implemented in the following patches. We deliberately do not document how often the hook will be invoked per rewriting command, but the interface is designed to keep that at "once". This would currently not matter too much, since both rebase and filter-branch are shellscripts and spawn many processes anyway. However, when a fast sequencer in C is implemented, it will be beneficial to only have to run the hook once. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation: spell 'git cmd' without dash throughoutThomas Rast2010-01-10
| | | | | | | | | | | | | | | The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.
* Sync with 1.6.5.6Junio C Hamano2009-12-10
|\ | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Remove post-upload-hookJunio C Hamano2009-12-10
| | | | | | | | | | | | | | This hook runs after "git fetch" in the repository the objects are fetched from as the user who fetched, and has security implications. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Use 'fast-forward' all over the placeFelipe Contreras2009-10-24
|/ | | | | | | It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* remove logical typo in documentation of sample update hookHeiko Voigt2009-09-14
| | | | | Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2009-09-07
|\ | | | | | | | | | | * maint: git-pull: do not mention --quiet and --verbose twice githooks.txt: put hooks into subsections
| * githooks.txt: put hooks into subsectionsBert Wesarg2009-09-07
| | | | | | | | | | | | | | | | | | | | All hooks are currently in its own section. Which may confuse users, because the section name serves as the hook file name and sections are all caps for man pages. Putting them into a new HOOKS section and each hook into a subsection keeps the case to lower case. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | upload-pack: feed "kind [clone|fetch]" to post-upload-pack hookJunio C Hamano2009-08-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A request to clone the repository does not give any "have" but asks for all the refs we offer with "want". When a request does not ask to clone the repository fully, but asks to fetch some refs into an empty repository, it will not give any "have" but its "want" won't ask for all the refs we offer. If we suppose (and I would say this is a rather big if) that it makes sense to distinguish these two cases, a hook cannot reliably do this alone. The hook can detect lack of "have" and bunch of "want", but there is no direct way to tell if the other end asked for all refs we offered, or merely most of them. Between the time we talked with the other end and the time the hook got called, we may have acquired more refs or lost some refs in the repository by concurrent operations. Given that we plan to introduce selective advertisement of refs with a protocol extension, it would become even more difficult for hooks to guess between these two cases. This adds "kind [clone|fetch]" to hook's input, as a stable interface to allow the hooks to tell these cases apart. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | upload-pack: add a trigger for post-upload-pack hookJunio C Hamano2009-08-28
|/ | | | | | | | | | | | | | | | | | | | | | | | | | After upload-pack successfully finishes its operation, post-upload-pack hook can be called for logging purposes. The hook is passed various pieces of information, one per line, from its standard input. Currently the following items can be fed to the hook, but more types of information may be added in the future: want SHA-1:: 40-byte hexadecimal object name the client asked to include in the resulting pack. Can occur one or more times in the input. have SHA-1:: 40-byte hexadecimal object name the client asked to exclude from the resulting pack, claiming to have them already. Can occur zero or more times in the input. time float:: Number of seconds spent for creating the packfile. size decimal:: Size of the resulting packfile in bytes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* githooks documentation: post-checkout hook is also called after cloneJens Lehmann2009-03-22
| | | | | | | | | The documentation of the post-checkout hook just talks about git-checkout. But recently git-clone was changed to call it too, unless the -no-checkout (-n) option is used. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2009-01-17
|\ | | | | | | | | | | | | | | | | | | | | | | * maint: Update draft release notes for 1.6.1.1 builtin-fsck: fix off by one head count t5540: clarify that http-push does not handle packed-refs on the remote http-push: when making directories, have a trailing slash in the path name http-push: fix off-by-path_len Documentation: let asciidoc align related options githooks.txt: add missing word builtin-commit.c: do not remove COMMIT_EDITMSG
| * Merge branch 'maint-1.6.0' into maintJunio C Hamano2009-01-17
| |\ | | | | | | | | | | | | | | | | | | | | | * maint-1.6.0: builtin-fsck: fix off by one head count Documentation: let asciidoc align related options githooks.txt: add missing word builtin-commit.c: do not remove COMMIT_EDITMSG
| | * githooks.txt: add missing wordStephan Beyer2009-01-17
| | | | | | | | | | | | | | | Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Fix Documentation typos surrounding the word 'handful'.Jon Loeliger2009-01-13
|/ / | | | | | | | | | | | | | | Some instances replaced by "handful of", others use the word "few", a couple get a slight rewording. Signed-off-by: Jon Loeliger <jdl@freescale.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | githooks documentation: add a note about the +x modeMiklos Vajna2008-12-17
|/ | | | | | | | | In a freshly initialized repo it is only necessary to rename the .sample hooks, but when using older repos (initialized with older git init) enabled the +x mode is still necessary - docuement this. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* docs: describe pre-rebase hookNanako Shiraishi2008-10-06
| | | | | | | | | Documentation/git-rebase.txt talks about pre-rebase hook, but it appears that Documentation/git-hooks.txt does not have corresponding entry for it. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Documentation: remove '\' in front of short optionsSZEDER Gábor2008-10-01
| | | | | | | | | | | ... because they show up in the man and html outputs. This escaping is only needed for double dashes to be compatible with older asciidoc versions; see commit e1ccf53 ([PATCH] Escape asciidoc's built-in em-dash replacement, 2005-09-12). Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* manpages: italicize git command names (which were in teletype font)Jonathan Nieder2008-07-05
| | | | | | | | | | | | | | | | | | | | | | | The names of git commands are not meant to be entered at the commandline; they are just names. So we render them in italics, as is usual for command names in manpages. Using doit () { perl -e 'for (<>) { s/\`(git-[^\`.]*)\`/'\''\1'\''/g; print }' } for i in git*.txt config.txt diff*.txt blame*.txt fetch*.txt i18n.txt \ merge*.txt pretty*.txt pull*.txt rev*.txt urls*.txt do doit <"$i" >"$i+" && mv "$i+" "$i" done git diff . Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation: be consistent about "git-" versus "git "Jonathan Nieder2008-07-01
| | | | | | | | | | | | | | | | | | | | Since the git-* commands are not installed in $(bindir), using "git-command <parameters>" in examples in the documentation is not a good idea. On the other hand, it is nice to be able to refer to each command using one hyphenated word. (There is no escaping it, anyway: man page names cannot have spaces in them.) This patch retains the dash in naming an operation, command, program, process, or action. Complete command lines that can be entered at a shell (i.e., without options omitted) are made to use the dashless form. The changes consist only of replacing some spaces with hyphens and vice versa. After a "s/ /-/g", the unpatched and patched versions are identical. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Ship sample hooks with .sample suffixJunio C Hamano2008-06-24
| | | | | | | | | | | | We used to mark hooks we ship as samples by making them unexecutable, but some filesystems cannot tell what is executable and what is not. This makes it much more explicit. The hooks are suffixed with .sample (but now are made executable), so enabling it is still one step operation (instead of "chmod +x $hook", you would do "mv $hook.sample $hook") but now they won't get accidentally enabled on systems without executable bit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* documentation: move git(7) to git(1)Christian Couder2008-06-06
| | | | | | | | As the "git" man page describes the "git" command at the end-user level, it seems better to move it to man section 1. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'cc/hooks-doc'Junio C Hamano2008-05-14
| | | | | * cc/hooks-doc: Documentation: rename "hooks.txt" to "githooks.txt" and make it a man page
* Documentation: rename "hooks.txt" to "githooks.txt" and make it a man pageChristian Couder2008-05-04
Also now "gitcli(5)" becomes "gitcli(7)". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>