summaryrefslogtreecommitdiff
path: root/Documentation/githooks.txt
AgeCommit message (Collapse)AuthorFilesLines
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
2013-03-25Merge branch 'wk/doc-pre-rebase' into maint-1.8.1Libravatar Junio C Hamano1-3/+5
The arguments given to pre-rebase hook were not documented. * wk/doc-pre-rebase: Documentation/githooks: Explain pre-rebase parameters
2013-03-01Sync with 1.8.1.5Libravatar Junio C Hamano1-1/+1
2013-03-01Documentation/githooks: Fix linkgitLibravatar Andrew Wong1-1/+1
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-24Documentation/githooks: Explain pre-rebase parametersLibravatar W. Trevor King1-3/+5
Descriptions borrowed from templates/hooks--pre-rebase.sample. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-05Merge branch 'ta/doc-no-small-caps'Libravatar Junio C Hamano1-4/+4
Update documentation to change "GIT" which was a poor-man's small caps to "Git". The latter was the intended spelling. Also change "git" spelled in all-lowercase to "Git" when it refers to the system as the whole or the concept it embodies, as opposed to the command the end users would type. * ta/doc-no-small-caps: Documentation: StGit is the right spelling, not StGIT Documentation: describe the "repository" in repository-layout Documentation: add a description for 'gitfile' to glossary Documentation: do not use undefined terms git-dir and git-file Documentation: the name of the system is 'Git', not 'git' Documentation: avoid poor-man's small caps GIT
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-4/+4
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-18push: Add support for pre-push hooksLibravatar Aaron Schrab1-0/+29
Add support for a pre-push hook which can be used to determine if the set of refs to be pushed is suitable for the target repository. The hook is run with two arguments specifying the name and location of the destination repository. Information about what is to be pushed is provided by sending lines of the following form to the hook's standard input: <local ref> SP <local sha1> SP <remote ref> SP <remote sha1> LF If the hook exits with a non-zero status, the push will be aborted. This will allow the script to determine if the push is acceptable based on the target repository and branch(es), the commits which are to be pushed, and even the source branches in some cases. Signed-off-by: Aaron Schrab <aaron@schrab.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-4/+4
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>
2011-01-10Documentation/githooks: post-rewrite-copy-notes never existedLibravatar Thomas Rast1-4/+0
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>
2010-03-12notes: implement helpers needed for note copying during rewriteLibravatar Thomas Rast1-0/+4
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>
2010-03-12Documentation: document post-rewrite hookLibravatar Thomas Rast1-0/+34
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>
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-32/+32
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.
2009-12-10Sync with 1.6.5.6Libravatar Junio C Hamano1-29/+0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-10Remove post-upload-hookLibravatar Junio C Hamano1-29/+0
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>
2009-10-24Use 'fast-forward' all over the placeLibravatar Felipe Contreras1-1/+1
It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-14remove logical typo in documentation of sample update hookLibravatar Heiko Voigt1-1/+1
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-07Merge branch 'maint'Libravatar Junio C Hamano1-15/+18
* maint: git-pull: do not mention --quiet and --verbose twice githooks.txt: put hooks into subsections
2009-09-07githooks.txt: put hooks into subsectionsLibravatar Bert Wesarg1-15/+18
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>
2009-08-28upload-pack: feed "kind [clone|fetch]" to post-upload-pack hookLibravatar Junio C Hamano1-0/+4
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>
2009-08-28upload-pack: add a trigger for post-upload-pack hookLibravatar Junio C Hamano1-0/+25
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>
2009-03-22githooks documentation: post-checkout hook is also called after cloneLibravatar Jens Lehmann1-0/+4
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>
2009-01-17Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* 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
2009-01-17Merge branch 'maint-1.6.0' into maintLibravatar Junio C Hamano1-1/+1
* 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
2009-01-17githooks.txt: add missing wordLibravatar Stephan Beyer1-1/+1
Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-13Fix Documentation typos surrounding the word 'handful'.Libravatar Jon Loeliger1-1/+1
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>
2008-12-17githooks documentation: add a note about the +x modeLibravatar Miklos Vajna1-0/+4
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>
2008-10-06docs: describe pre-rebase hookLibravatar Nanako Shiraishi1-0/+7
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>
2008-10-01Documentation: remove '\' in front of short optionsLibravatar SZEDER Gábor1-3/+3
... 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>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-37/+37
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>