git/Documentation/git-unpack-objects.txt, branch v2.4.9

doc: fix inconsistent spelling of "packfile"

2015-05-22T16:00:17Z

Fix remaining instances where "pack-file" is used instead of "packfile". Some places remain where we still use "pack-file", This is the case when we explicitly refer to a file with a ".pack" extension as opposed to a data source providing a pack data stream. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

git-unpack-objects.txt: fix inconsistent spelling of "packfile"

2015-05-17T18:24:58Z

Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'vd/doc-unpack-objects'

2013-11-04T22:58:16Z

* vd/doc-unpack-objects: Documentation: "pack-file" is not literal in unpack-objects Documentation: restore a space in unpack-objects usage

Documentation: "pack-file" is not literal in unpack-objects

2013-11-01T16:13:35Z

Make it clear that "pack-file" is not to be spelled as is in the unpack-objects usage. Signed-off-by: Vivien Didelot Signed-off-by: Junio C Hamano

Documentation: restore a space in unpack-objects usage

2013-10-31T22:11:28Z

The commit 87b7b84 removed a space in the unpack-objects usage, which makes the synopsis a bit confusing. This patch simply restores it. Signed-off-by: Vivien Didelot Signed-off-by: Junio C Hamano

Documentation: use [verse] for SYNOPSIS sections

2011-07-06T21:26:26Z

The SYNOPSIS sections of most commands that span several lines already use [verse] to retain line breaks. Most commands that don't span several lines seem not to use [verse]. In the HTML output, [verse] does not only preserve line breaks, but also makes the section indented, which causes a slight inconsistency between commands that use [verse] and those that don't. Use [verse] in all SYNOPSIS sections for consistency. Also remove the blank lines from git-fetch.txt and git-rebase.txt to align with the other man pages. In the case of git-rebase.txt, which already uses [verse], the blank line makes the [verse] not apply to the last line, so removing the blank line also makes the formatting within the document more consistent. While at it, add single quotes to 'git cvsimport' for consistency with other commands. Signed-off-by: Martin von Zweigbergk Signed-off-by: Junio C Hamano

doc: drop author/documentation sections from most pages

2011-03-11T15:59:16Z

The point of these sections is generally to: 1. Give credit where it is due. 2. Give the reader an idea of where to ask questions or file bug reports. But they don't do a good job of either case. For (1), they are out of date and incomplete. A much more accurate answer can be gotten through shortlog or blame. For (2), the correct contact point is generally git@vger, and even if you wanted to cc the contact point, the out-of-date and incomplete fields mean you're likely sending to somebody useless. So let's drop the fields entirely from all manpages except git(1) itself. We already point people to the mailing list for bug reports there, and we can update the Authors section to give credit to the major contributors and point to shortlog and blame for more information. Each page has a "This is part of git" footer, so people can follow that to the main git manpage.

Documentation formatting and cleanup

2008-07-02T00:20:16Z

Following what appears to be the predominant style, format names of commands and commandlines both as `teletype text`. While we're at it, add articles ("a" and "the") in some places, italicize the name of the command in the manual page synopsis line, and add a comma or two where it seems appropriate. 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

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