delta/git.git/Documentation/git-hash-object.txt, branch ws/curl-http-proxy-over-https

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

git-hash-object.txt: document --literally option

2015-05-04T21:19:23+00:00

Document the git-hash-object --literally option added by 5ba9a93
(hash-object: add --literally option, 2014-09-11).

While here, also correct a minor typesetting oversight.

Signed-off-by: Eric Sunshine 
Signed-off-by: Junio C Hamano

Documentation: the name of the system is 'Git', not 'git'

2013-02-01T21:53:33+00:00

Signed-off-by: Thomas Ackermann 
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: spelling fixes

2010-07-20T23:59:17+00:00

[jc: with wording changes from Jonathan Nieder]

Signed-off-by: Junio C Hamano

hash-object: support --stdin-paths with --no-filters

2010-03-05T10:57:54+00:00

Signed-off-by: Erik Faye-Lund 
Acked-by: Junio C Hamano

Documentation: spell 'git cmd' without dash throughout

2010-01-10T12:01:28+00:00

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.

add --no-filters option to git hash-object

2008-08-03T20:38:22+00:00

The new option allows the contents to be hashed as is, ignoring any input
filter that would have been chosen by the attributes mechanism.

This option is incompatible with --path and --stdin-paths options.

Signed-off-by: Dmitry Potapov 
Signed-off-by: Junio C Hamano

add --path option to git hash-object

2008-08-03T20:33:06+00:00

The --path option allows us to pretend as if the contents being hashed
came from the specified path, and affects which input filter is used via
the attributes mechanism.  This is useful for hashing a temporary file
whose name is different from the path that is meant to have the hashed
contents.

Signed-off-by: Dmitry Potapov 
Signed-off-by: Junio C Hamano

correct usage help string for git-hash-object

2008-08-03T20:23:15+00:00

The usage string is corrected to make it fit in 80 columns and to make it
unequivocal about what options can be used with --stdin-paths.

Signed-off-by: Dmitry Potapov 
Signed-off-by: Junio C Hamano