git/Documentation/git-replace.txt, branch v2.0.2

replace info: rename 'full' to 'long' and clarify in-code symbols

2013-12-30T20:33:11Z

Enum names SHORT/MEDIUM/FULL were too broad to be descriptive. And they clashed with built-in symbols on platforms like Windows. Clarify by giving them REPLACE_FORMAT_ prefix. Rename 'full' format in "git replace --format=" to 'long', to match others (i.e. 'short' and 'medium'). Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

Documentation/git-replace: describe --format option

2013-12-12T19:53:49Z

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

Doc: 'replace' merge and non-merge commits

2013-09-09T15:16:30Z

Merges are often treated as special case objects so tell users that they are not special here. Signed-off-by: Philip Oakley Signed-off-by: Junio C Hamano

replace: allow long option names

2013-09-06T20:32:24Z

It is now standard practice in Git to have both short and long option names. So let's give a long option name to the git replace options too. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

Documentation/replace: add Creating Replacement Objects section

2013-09-06T20:29:53Z

There were no hints in the documentation about how to create replacement objects. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

Documentation/replace: state that objects must be of the same type

2013-09-06T20:25:21Z

A previous patch ensures that both the replaced and the replacement objects passed to git replace must be of the same type, except if -f option is used. While at it state that there is no other restriction on both objects. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

The name of the hash function is "SHA-1", not "SHA1"

2013-04-15T18:08:37Z

Use "SHA-1" instead of "SHA1" whenever we talk about the hash function. When used as a programming symbol, we keep "SHA1". Signed-off-by: Thomas Ackermann Signed-off-by: Junio C Hamano

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

Documentation: do not mention .git/refs/* directories

2012-08-06T21:04:16Z

It is an implementation detail that a new tag is created by adding a file in the .git/refs/tags directory. The only thing the user needs to know is that a "git tag" creates a ref in the refs/tags namespace, and without "-f", it does not overwrite an existing tag. Inspired by a report from 乙酸鋰 ; I think I caught all the existing mention in Documentation/ directory in the tip of 1.7.9.X maintenance track, but we may have added new ones since then. 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.