48bb914ed6
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.
35 lines
931 B
Plaintext
35 lines
931 B
Plaintext
git-patch-id(1)
|
|
===============
|
|
|
|
NAME
|
|
----
|
|
git-patch-id - Compute unique ID for a patch
|
|
|
|
SYNOPSIS
|
|
--------
|
|
'git patch-id' < <patch>
|
|
|
|
DESCRIPTION
|
|
-----------
|
|
A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with
|
|
whitespace and line numbers ignored. As such, it's "reasonably stable", but at
|
|
the same time also reasonably unique, i.e., two patches that have the same "patch
|
|
ID" are almost guaranteed to be the same thing.
|
|
|
|
IOW, you can use this thing to look for likely duplicate commits.
|
|
|
|
When dealing with 'git diff-tree' output, it takes advantage of
|
|
the fact that the patch is prefixed with the object name of the
|
|
commit, and outputs two 40-byte hexadecimal strings. The first
|
|
string is the patch ID, and the second string is the commit ID.
|
|
This can be used to make a mapping from patch ID to commit ID.
|
|
|
|
OPTIONS
|
|
-------
|
|
<patch>::
|
|
The diff to create the ID of.
|
|
|
|
GIT
|
|
---
|
|
Part of the linkgit:git[1] suite
|