delta/git.git/Documentation/git-unpack-objects.txt, branch ws/curl-http-proxy-over-https

unpack-objects: add --max-input-size= option

2016-08-24T19:31:05+00:00

When receiving a pack-file, it can be useful to abort the
`git unpack-objects`, if the pack-file is too big.

Signed-off-by: Christian Couder 
Signed-off-by: Junio C Hamano

usage: do not insist that standard input must come from a file

2015-10-16T22:27:52+00:00

The synopsys text and the usage string of subcommands that read list
of things from the standard input are often shown like this:

	git gostak [--distim] < 

This is problematic in a number of ways:

 * The way to use these commands is more often to feed them the
   output from another command, not feed them from a file.

 * Manual pages outside Git, commands that operate on the data read
   from the standard input, e.g "sort", "grep", "sed", etc., are not
   described with such a "< redirection-from-file" in their synopsys
   text.  Our doing so introduces inconsistency.

 * We do not insist on where the output should go, by saying

	git gostak [--distim] <  > 

 * As it is our convention to enclose placeholders inside ,
   the redirection operator followed by a placeholder filename
   becomes very hard to read, both in the documentation and in the
   help text.

Let's clean them all up, after making sure that the documentation
clearly describes the modes that take information from the standard
input and what kind of things are expected on the input.

[jc: stole example for fmt-merge-msg from Jonathan]

Helped-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

doc: fix inconsistent spelling of "packfile"

2015-05-22T16:00:17+00:00

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:58+00:00

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

Merge branch 'vd/doc-unpack-objects'

2013-11-04T22:58:16+00:00

* 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:35+00:00

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:28+00:00

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:26+00:00

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:16+00:00

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:16+00:00

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