undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
26fc326044
git-commit-vandalism/Documentation/git-patch-id.txt

70 lines
2.4 KiB
Plaintext
Raw Normal View History

Add placeholders for missing documents. The text does not say anything interesting, but at least the author list should reflect something close to reality. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 10:49:47 +02:00
git-patch-id(1)
===============
NAME
----
Documentation: sync git.txt command list and manual page title Also reorders a handful entries to make each list sorted alphabetically. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19 00:53:37 +01:00
git-patch-id - Compute unique ID for a patch
Add placeholders for missing documents. The text does not say anything interesting, but at least the author list should reflect something close to reality. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 10:49:47 +02:00
SYNOPSIS
--------
Documentation: use [verse] for SYNOPSIS sections The SYNOPSIS sections of most commands that span several lines already use [verse] to retain line breaks. Most commands that don't span several lines seem not to use [verse]. In the HTML output, [verse] does not only preserve line breaks, but also makes the section indented, which causes a slight inconsistency between commands that use [verse] and those that don't. Use [verse] in all SYNOPSIS sections for consistency. Also remove the blank lines from git-fetch.txt and git-rebase.txt to align with the other man pages. In the case of git-rebase.txt, which already uses [verse], the blank line makes the [verse] not apply to the last line, so removing the blank line also makes the formatting within the document more consistent. While at it, add single quotes to 'git cvsimport' for consistency with other commands. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-02 04:38:26 +02:00
[verse]
builtin: patch-id: add --verbatim as a command mode There are situations where the user might not want the default setting where patch-id strips all whitespace. They might be working in a language where white space is syntactically important, or they might have CI testing that enforces strict whitespace linting. In these cases, a whitespace change would result in the patch fundamentally changing, and thus deserving of a different id. Add a new mode that is exclusive of --stable and --unstable called --verbatim. It also corresponds to the config patchid.verbatim = true. In this mode, the stable algorithm is used and whitespace is not stripped from the patch text. Users of --unstable mainly care about compatibility with old git versions, which unstripping the whitespace would break. Thus there isn't a usecase for the combination of --verbatim and --unstable, and we don't expose this so as to not add maintainence burden. Signed-off-by: Jerry Zhang <jerry@skydio.com> fixes https://github.com/Skydio/revup/issues/2 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-24 22:07:43 +02:00
'git patch-id' [--stable | --unstable | --verbatim]
Add placeholders for missing documents. The text does not say anything interesting, but at least the author list should reflect something close to reality. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 10:49:47 +02: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 20:27:42 +02:00
Read a patch from the standard input and compute the patch ID for it.
patch-id: make it stable against hunk reordering Patch id changes if users reorder file diffs that make up a patch. As the result is functionally equivalent, a different patch id is surprising to many users. In particular, reordering files using diff -O is helpful to make patches more readable (e.g. API header diff before implementation diff). Add an option to change patch-id behaviour making it stable against these kinds of patch change: calculate SHA1 hash for each hunk separately and sum all hashes (using a symmetrical sum) to get patch id We use a 20byte sum and not xor - since xor would give 0 output for patches that have two identical diffs, which isn't all that unlikely (e.g. append the same line in two places). The new behaviour is enabled - when patchid.stable is true - when --stable flag is present Using a new flag --unstable or setting patchid.stable to false force the historical behaviour. In the documentation, clarify that patch ID can now be a sum of hashes, not a hash. Document how command line and config options affect the behaviour. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-27 20:15:44 +02:00
A "patch ID" is nothing but a sum of SHA-1 of the file diffs associated with a
builtin: patch-id: add --verbatim as a command mode There are situations where the user might not want the default setting where patch-id strips all whitespace. They might be working in a language where white space is syntactically important, or they might have CI testing that enforces strict whitespace linting. In these cases, a whitespace change would result in the patch fundamentally changing, and thus deserving of a different id. Add a new mode that is exclusive of --stable and --unstable called --verbatim. It also corresponds to the config patchid.verbatim = true. In this mode, the stable algorithm is used and whitespace is not stripped from the patch text. Users of --unstable mainly care about compatibility with old git versions, which unstripping the whitespace would break. Thus there isn't a usecase for the combination of --verbatim and --unstable, and we don't expose this so as to not add maintainence burden. Signed-off-by: Jerry Zhang <jerry@skydio.com> fixes https://github.com/Skydio/revup/issues/2 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-24 22:07:43 +02:00
patch, with 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.
Add placeholders for missing documents. The text does not say anything interesting, but at least the author list should reflect something close to reality. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 10:49:47 +02:00
builtin: patch-id: add --verbatim as a command mode There are situations where the user might not want the default setting where patch-id strips all whitespace. They might be working in a language where white space is syntactically important, or they might have CI testing that enforces strict whitespace linting. In these cases, a whitespace change would result in the patch fundamentally changing, and thus deserving of a different id. Add a new mode that is exclusive of --stable and --unstable called --verbatim. It also corresponds to the config patchid.verbatim = true. In this mode, the stable algorithm is used and whitespace is not stripped from the patch text. Users of --unstable mainly care about compatibility with old git versions, which unstripping the whitespace would break. Thus there isn't a usecase for the combination of --verbatim and --unstable, and we don't expose this so as to not add maintainence burden. Signed-off-by: Jerry Zhang <jerry@skydio.com> fixes https://github.com/Skydio/revup/issues/2 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-24 22:07:43 +02:00
The main usecase for this command is to look for likely duplicate commits.
Add placeholders for missing documents. The text does not say anything interesting, but at least the author list should reflect something close to reality. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 10:49:47 +02:00
Documentation: spell 'git cmd' without dash throughout 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.
2010-01-10 00:33:00 +01:00
When dealing with 'git diff-tree' output, it takes advantage of
Document git-patch-id a bit better. Pavel Roskin wondered what the SHA1 output at the beginning of git-diff-tree was about. The only consumer of that information so far is this git-patch-id command, which was inadequately documented. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-28 11:39:56 +02:00
the fact that the patch is prefixed with the object name of the
Grammar fixes to "merge" and "patch-id" docs Signed-off-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-25 19:23:42 +01:00
commit, and outputs two 40-byte hexadecimal strings. The first
Document git-patch-id a bit better. Pavel Roskin wondered what the SHA1 output at the beginning of git-diff-tree was about. The only consumer of that information so far is this git-patch-id command, which was inadequately documented. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-28 11:39:56 +02: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.
Add placeholders for missing documents. The text does not say anything interesting, but at least the author list should reflect something close to reality. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 10:49:47 +02:00
OPTIONS
-------
patch-id: make it stable against hunk reordering Patch id changes if users reorder file diffs that make up a patch. As the result is functionally equivalent, a different patch id is surprising to many users. In particular, reordering files using diff -O is helpful to make patches more readable (e.g. API header diff before implementation diff). Add an option to change patch-id behaviour making it stable against these kinds of patch change: calculate SHA1 hash for each hunk separately and sum all hashes (using a symmetrical sum) to get patch id We use a 20byte sum and not xor - since xor would give 0 output for patches that have two identical diffs, which isn't all that unlikely (e.g. append the same line in two places). The new behaviour is enabled - when patchid.stable is true - when --stable flag is present Using a new flag --unstable or setting patchid.stable to false force the historical behaviour. In the documentation, clarify that patch ID can now be a sum of hashes, not a hash. Document how command line and config options affect the behaviour. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-27 20:15:44 +02:00
builtin: patch-id: add --verbatim as a command mode There are situations where the user might not want the default setting where patch-id strips all whitespace. They might be working in a language where white space is syntactically important, or they might have CI testing that enforces strict whitespace linting. In these cases, a whitespace change would result in the patch fundamentally changing, and thus deserving of a different id. Add a new mode that is exclusive of --stable and --unstable called --verbatim. It also corresponds to the config patchid.verbatim = true. In this mode, the stable algorithm is used and whitespace is not stripped from the patch text. Users of --unstable mainly care about compatibility with old git versions, which unstripping the whitespace would break. Thus there isn't a usecase for the combination of --verbatim and --unstable, and we don't expose this so as to not add maintainence burden. Signed-off-by: Jerry Zhang <jerry@skydio.com> fixes https://github.com/Skydio/revup/issues/2 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-24 22:07:43 +02:00
--verbatim::
Calculate the patch-id of the input as it is given, do not strip
any whitespace.
This is the default if patchid.verbatim is true.
patch-id: make it stable against hunk reordering Patch id changes if users reorder file diffs that make up a patch. As the result is functionally equivalent, a different patch id is surprising to many users. In particular, reordering files using diff -O is helpful to make patches more readable (e.g. API header diff before implementation diff). Add an option to change patch-id behaviour making it stable against these kinds of patch change: calculate SHA1 hash for each hunk separately and sum all hashes (using a symmetrical sum) to get patch id We use a 20byte sum and not xor - since xor would give 0 output for patches that have two identical diffs, which isn't all that unlikely (e.g. append the same line in two places). The new behaviour is enabled - when patchid.stable is true - when --stable flag is present Using a new flag --unstable or setting patchid.stable to false force the historical behaviour. In the documentation, clarify that patch ID can now be a sum of hashes, not a hash. Document how command line and config options affect the behaviour. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-27 20:15:44 +02: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.
builtin: patch-id: add --verbatim as a command mode There are situations where the user might not want the default setting where patch-id strips all whitespace. They might be working in a language where white space is syntactically important, or they might have CI testing that enforces strict whitespace linting. In these cases, a whitespace change would result in the patch fundamentally changing, and thus deserving of a different id. Add a new mode that is exclusive of --stable and --unstable called --verbatim. It also corresponds to the config patchid.verbatim = true. In this mode, the stable algorithm is used and whitespace is not stripped from the patch text. Users of --unstable mainly care about compatibility with old git versions, which unstripping the whitespace would break. Thus there isn't a usecase for the combination of --verbatim and --unstable, and we don't expose this so as to not add maintainence burden. Signed-off-by: Jerry Zhang <jerry@skydio.com> fixes https://github.com/Skydio/revup/issues/2 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-24 22:07:43 +02:00
- All whitespace within the patch is ignored and does not affect the id.
patch-id: make it stable against hunk reordering Patch id changes if users reorder file diffs that make up a patch. As the result is functionally equivalent, a different patch id is surprising to many users. In particular, reordering files using diff -O is helpful to make patches more readable (e.g. API header diff before implementation diff). Add an option to change patch-id behaviour making it stable against these kinds of patch change: calculate SHA1 hash for each hunk separately and sum all hashes (using a symmetrical sum) to get patch id We use a 20byte sum and not xor - since xor would give 0 output for patches that have two identical diffs, which isn't all that unlikely (e.g. append the same line in two places). The new behaviour is enabled - when patchid.stable is true - when --stable flag is present Using a new flag --unstable or setting patchid.stable to false force the historical behaviour. In the documentation, clarify that patch ID can now be a sum of hashes, not a hash. Document how command line and config options affect the behaviour. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-27 20:15:44 +02:00
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
builtin: patch-id: add --verbatim as a command mode There are situations where the user might not want the default setting where patch-id strips all whitespace. They might be working in a language where white space is syntactically important, or they might have CI testing that enforces strict whitespace linting. In these cases, a whitespace change would result in the patch fundamentally changing, and thus deserving of a different id. Add a new mode that is exclusive of --stable and --unstable called --verbatim. It also corresponds to the config patchid.verbatim = true. In this mode, the stable algorithm is used and whitespace is not stripped from the patch text. Users of --unstable mainly care about compatibility with old git versions, which unstripping the whitespace would break. Thus there isn't a usecase for the combination of --verbatim and --unstable, and we don't expose this so as to not add maintainence burden. Signed-off-by: Jerry Zhang <jerry@skydio.com> fixes https://github.com/Skydio/revup/issues/2 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-24 22:07:43 +02:00
by git 1.9 and older and whitespace is ignored. 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.
patch-id: make it stable against hunk reordering Patch id changes if users reorder file diffs that make up a patch. As the result is functionally equivalent, a different patch id is surprising to many users. In particular, reordering files using diff -O is helpful to make patches more readable (e.g. API header diff before implementation diff). Add an option to change patch-id behaviour making it stable against these kinds of patch change: calculate SHA1 hash for each hunk separately and sum all hashes (using a symmetrical sum) to get patch id We use a 20byte sum and not xor - since xor would give 0 output for patches that have two identical diffs, which isn't all that unlikely (e.g. append the same line in two places). The new behaviour is enabled - when patchid.stable is true - when --stable flag is present Using a new flag --unstable or setting patchid.stable to false force the historical behaviour. In the documentation, clarify that patch ID can now be a sum of hashes, not a hash. Document how command line and config options affect the behaviour. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-27 20:15:44 +02:00
This is the default.
Add placeholders for missing documents. The text does not say anything interesting, but at least the author list should reflect something close to reality. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 10:49:47 +02:00
GIT
---
documentation: move git(7) to git(1) As the "git" man page describes the "git" command at the end-user level, it seems better to move it to man section 1. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-06 09:07:32 +02:00
Part of the linkgit:git[1] suite
Reference in New Issue Copy Permalink