git/Documentation/git-hash-object.txt, branch v2.1.2

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

2013-02-01T21:53:33Z

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

2010-07-20T23:59:17Z

[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:54Z

Signed-off-by: Erik Faye-Lund Acked-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.

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

2008-08-03T20:38:22Z

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:06Z

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:15Z

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

Update my e-mail address

2008-07-21T19:14:42Z

The old cox.net address is still getting mails from gitters. 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