git/Documentation/git-init.txt, branch v1.7.3.4

Use parentheses and `...' where appropriate

2010-10-08T19:31:07Z

Remove some stray usage of other bracket types and asterisks for the same purpose. Signed-off-by: Štěpán Němec Acked-by: Jonathan Nieder Signed-off-by: Junio C Hamano

Add a "TEMPLATE DIRECTORY" section to git-init[1].

2010-02-17T20:17:53Z

Create a more inoformative section to describe template directory and refer to it in config.txt and with the '--template' option of git-init and git-clone commands. Signed-off-by: Steven Drake Signed-off-by: Junio C Hamano

Documentation: spell 'git cmd' without dash throughout

2010-01-10T12:01:28Z

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.

git init: optionally allow a directory argument

2009-07-25T09:17:54Z

When starting a new repository, I see my students often say % git init newrepo and curse git. They could say % mkdir newrepo; cd newrepo; git init but allowing it as an obvious short-cut may be nicer. Signed-off-by: Nanako Shiraishi Signed-off-by: Junio C Hamano

Update docs on behaviour of 'core.sharedRepository' and 'git init --shared'

2009-04-18T19:51:06Z

This documentation update is needed to reflect the recent changes where "core.sharedRepository = 0mode" was changed to set, not loosen, the repository permissions. Signed-off-by: Johan Herland Signed-off-by: Junio C Hamano

manpages: italicize git command names (which were in teletype font)

2008-07-05T18:24:40Z

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 Signed-off-by: Junio C Hamano

Documentation: be consistent about "git-" versus "git "

2008-07-02T00:20:15Z

Since the git-* commands are not installed in $(bindir), using "git-command " 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 Signed-off-by: Junio C Hamano

Docs: Use "-l::\n--long\n" format in OPTIONS sections

2008-06-08T20:46:38Z

The OPTIONS section of a documentation file contains a list of the options a git command accepts. Currently there are several variants to describe the case that different options (almost) do the same in the OPTIONS section. Some are: -f, --foo:: -f|--foo:: -f | --foo:: But AsciiDoc has the special form: -f:: --foo:: This patch applies this form to the documentation of the whole git suite, and removes useless em-dash prevention, so \--foo becomes --foo. Signed-off-by: Stephan Beyer Signed-off-by: Junio C Hamano

documentation: move git(7) to git(1)

2008-06-06T18:18:28Z

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 Signed-off-by: Junio C Hamano

git-init: accept --bare option

2008-05-29T01:31:19Z

It is unfortunate that "git init --bare" does not work and the only reason why "init" did not learn its own "--bare" option is because "git --bare init" already does the job (and as an option to the git 'potty', it is more generic solution). This teaches "git init" its own "--bare" option, so that both "git --bare init" and "git init --bare" works mostly the same way. [jc: rewrote the log message and added test] Signed-off-by: Luciano Rocha Signed-off-by: Junio C Hamano