2005-08-23 08:49:47 +00:00
|
|
|
git-patch-id(1)
|
|
|
|
|
===============
|
|
|
|
|
|
|
|
|
|
NAME
|
|
|
|
|
----
|
2007-01-18 23:53:37 +00:00
|
|
|
git-patch-id - Compute unique ID for a patch
|
2005-08-23 08:49:47 +00:00
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
|
--------
|
2011-07-02 02:38:26 +00:00
|
|
|
[verse]
|
usage: do not insist that standard input must come from a file
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] < <list-of-doshes>
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] < <list-of-doshes> > <output>
* As it is our convention to enclose placeholders inside <braket>,
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 <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16 18:27:42 +00:00
|
|
|
'git patch-id' [--stable | --unstable]
|
2005-08-23 08:49:47 +00:00
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
|
-----------
|
usage: do not insist that standard input must come from a file
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] < <list-of-doshes>
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] < <list-of-doshes> > <output>
* As it is our convention to enclose placeholders inside <braket>,
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 <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16 18:27:42 +00:00
|
|
|
Read a patch from the standard input and compute the patch ID for it.
|
|
|
|
|
|
2014-04-27 18:15:44 +00:00
|
|
|
A "patch ID" is nothing but a sum of SHA-1 of the file diffs 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.
|
2005-08-23 08:49:47 +00:00
|
|
|
|
2005-08-27 01:18:48 +00:00
|
|
|
IOW, you can use this thing to look for likely duplicate commits.
|
2005-08-23 08:49:47 +00:00
|
|
|
|
2010-01-09 23:33:00 +00:00
|
|
|
When dealing with 'git diff-tree' output, it takes advantage of
|
2005-10-28 09:39:56 +00:00
|
|
|
the fact that the patch is prefixed with the object name of the
|
2009-03-25 18:23:42 +00:00
|
|
|
commit, and outputs two 40-byte hexadecimal strings. The first
|
2005-10-28 09:39:56 +00:00
|
|
|
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.
|
|
|
|
|
|
2005-08-23 08:49:47 +00:00
|
|
|
OPTIONS
|
|
|
|
|
-------
|
2014-04-27 18:15:44 +00:00
|
|
|
|
|
|
|
|
--stable::
|
|
|
|
|
Use a "stable" sum of hashes as the patch ID. With this option:
|
|
|
|
|
- Reordering file diffs that make up a patch does not affect the ID.
|
|
|
|
|
In particular, two patches produced by comparing the same two trees
|
|
|
|
|
with two different settings for "-O<orderfile>" result in the same
|
|
|
|
|
patch ID signature, thereby allowing the computed result to be used
|
|
|
|
|
as a key to index some meta-information about the change between
|
|
|
|
|
the two trees;
|
|
|
|
|
|
|
|
|
|
- Result is different from the value produced by git 1.9 and older
|
|
|
|
|
or produced when an "unstable" hash (see --unstable below) is
|
|
|
|
|
configured - even when used on a diff output taken without any use
|
|
|
|
|
of "-O<orderfile>", thereby making existing databases storing such
|
|
|
|
|
"unstable" or historical patch-ids unusable.
|
|
|
|
|
|
|
|
|
|
This is the default if patchid.stable is set to true.
|
|
|
|
|
|
|
|
|
|
--unstable::
|
|
|
|
|
Use an "unstable" hash as the patch ID. With this option,
|
|
|
|
|
the result produced is compatible with the patch-id value produced
|
|
|
|
|
by git 1.9 and older. Users with pre-existing databases storing
|
|
|
|
|
patch-ids produced by git 1.9 and older (who do not deal with reordered
|
|
|
|
|
patches) may want to use this option.
|
|
|
|
|
|
|
|
|
|
This is the default.
|
|
|
|
|
|
2005-08-23 08:49:47 +00:00
|
|
|
GIT
|
|
|
|
|
---
|
2008-06-06 07:07:32 +00:00
|
|
|
Part of the linkgit:git[1] suite
|