From: "Michael S. Tsirkin" <mst@redhat.com> Date: 2016-06-15 22:58:53
The id is already different for binary files.
Let's document that they are similar, not identical.
Cc: Jonathan Nieder <redacted>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
Documentation/git-cherry.txt | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
@@ -13,12 +13,13 @@ SYNOPSIS DESCRIPTION ----------- The changeset (or "diff") of each commit between the fork-point and <head>-is compared against each commit between the fork-point and <upstream>.-The commits are compared with their 'patch id', obtained from-the 'git patch-id' program.+is compared against diff of each commit between the fork-point and <upstream>.+The diffs are compared with their diff id (sha1) calculated after removing+any whitespace and line numbers (similar but not necessarily identical+to 'patch id', obtained from the 'git patch-id' program). Every commit that doesn't exist in the <upstream> branch-has its id (sha1) reported, prefixed by a symbol. The ones that have+has its diff id (sha1) reported, prefixed by a symbol. The ones that have equivalent change already in the <upstream> branch are prefixed with a minus (-) sign, and those that only exist in the <head> branch are prefixed with a plus (+) symbol:
@@ -13,12 +13,13 @@ SYNOPSIS DESCRIPTION ----------- The changeset (or "diff") of each commit between the fork-point and <head>-is compared against each commit between the fork-point and <upstream>.+is compared against diff of each commit between the fork-point and <upstream>.
I think the old version of this sentence is clearer.
-The commits are compared with their 'patch id', obtained from
-the 'git patch-id' program.
+The diffs are compared with their diff id (sha1) calculated after removing
+any whitespace and line numbers (similar but not necessarily identical
+to 'patch id', obtained from the 'git patch-id' program).
The hash used internally is just an implementation detail, so maybe this
sentence could just be dropped?
Every commit that doesn't exist in the <upstream> branch
-has its id (sha1) reported, prefixed by a symbol. The ones that have
+has its diff id (sha1) reported, prefixed by a symbol. The ones that have
Confusingly, here 'id' means 'commit name'. For example:
$ git log --oneline -1 sb/repack-in-c
0b63c6a repack: improve warnings about failure of renaming and removing files
$ git cherry sb/repack-in-c^ sb/repack-in-c
+ 0b63c6a5b78f3fdd8c4e4fed4e535e7f4eed4257
Hope that helps,
Jonathan
@@ -13,12 +13,13 @@ SYNOPSIS DESCRIPTION ----------- The changeset (or "diff") of each commit between the fork-point and <head>-is compared against each commit between the fork-point and <upstream>.+is compared against diff of each commit between the fork-point and <upstream>.
I think the old version of this sentence is clearer.
quoted
-The commits are compared with their 'patch id', obtained from
-the 'git patch-id' program.
+The diffs are compared with their diff id (sha1) calculated after removing
+any whitespace and line numbers (similar but not necessarily identical
+to 'patch id', obtained from the 'git patch-id' program).
The hash used internally is just an implementation detail, so maybe this
sentence could just be dropped?
I think the fact whitespace is ignored is relevant to users, no?
We probably should drop talking about hash here.
quoted
Every commit that doesn't exist in the <upstream> branch
-has its id (sha1) reported, prefixed by a symbol. The ones that have
+has its diff id (sha1) reported, prefixed by a symbol. The ones that have
Confusingly, here 'id' means 'commit name'. For example:
$ git log --oneline -1 sb/repack-in-c
0b63c6a repack: improve warnings about failure of renaming and removing files
$ git cherry sb/repack-in-c^ sb/repack-in-c
+ 0b63c6a5b78f3fdd8c4e4fed4e535e7f4eed4257
Hope that helps,
Jonathan
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:58:53
Michael S. Tsirkin wrote:
On Tue, Sep 24, 2013 at 03:14:09PM -0700, Jonathan Nieder wrote:
quoted
Michael S. Tsirkin wrote:
quoted
quoted
-The commits are compared with their 'patch id', obtained from
-the 'git patch-id' program.
+The diffs are compared with their diff id (sha1) calculated after removing
+any whitespace and line numbers (similar but not necessarily identical
+to 'patch id', obtained from the 'git patch-id' program).
The hash used internally is just an implementation detail, so maybe this
sentence could just be dropped?
I think the fact whitespace is ignored is relevant to users, no?
We probably should drop talking about hash here.
Ah, good point. So, something like the following, then?
Whitespace and line numbers are ignored when comparing the diffs,
similarly to linkgit:git-patch-id[1].
Maybe some other wording would make it clearer that we are not using
"git diff -w" output.
From: "Michael S. Tsirkin" <mst@redhat.com> Date: 2016-06-15 22:58:53
On Tue, Sep 24, 2013 at 03:44:31PM -0700, Jonathan Nieder wrote:
Michael S. Tsirkin wrote:
quoted
On Tue, Sep 24, 2013 at 03:14:09PM -0700, Jonathan Nieder wrote:
quoted
Michael S. Tsirkin wrote:
quoted
quoted
quoted
-The commits are compared with their 'patch id', obtained from
-the 'git patch-id' program.
+The diffs are compared with their diff id (sha1) calculated after removing
+any whitespace and line numbers (similar but not necessarily identical
+to 'patch id', obtained from the 'git patch-id' program).
The hash used internally is just an implementation detail, so maybe this
sentence could just be dropped?
I think the fact whitespace is ignored is relevant to users, no?
We probably should drop talking about hash here.
Ah, good point. So, something like the following, then?
Whitespace and line numbers are ignored when comparing the diffs,
similarly to linkgit:git-patch-id[1].
Maybe some other wording would make it clearer that we are not using
"git diff -w" output.