Hi,
Let's consider the following patch (======= are delimiters):
=======
commit 8db0161b9bb897d9cbe68bc1ed8ba8f43f39da00
Author: Tester Test [off-list ref]
Date: Mon Aug 20 20:19:19 2018 +0200
another master commit
diff --git a/3.txt b/3.txt
new file mode 100644
index 0000000..e69de29
commit 4d5917beba89d2e267ea632b7e78958b3736eabe
Author: Tester Test [off-list ref]
Date: Mon Aug 20 20:19:19 2018 +0200
squashed
diff --git a/1.txt b/1.txt
new file mode 100644
index 0000000..e69de29
=======
In `git patch-id` v2.46.0, this gives the output of :
85da93bf95da4433da1ce20a2b822ec3c72a1b92
8db0161b9bb897d9cbe68bc1ed8ba8f43f39da00
3a7470bbbca005289ab50c5297a4d7712cad5a81
4d5917beba89d2e267ea632b7e78958b3736eabe
but in v2.46.1 (apparently after the commit
a6e9429f728d088999b815c25adbd2f2c115e051 aka `patch-id: tighten code
to detect the patch header`):
85da93bf95da4433da1ce20a2b822ec3c72a1b92
8db0161b9bb897d9cbe68bc1ed8ba8f43f39da00
3a7470bbbca005289ab50c5297a4d7712cad5a81
0000000000000000000000000000000000000000
Same for 3+ commits in the input: correct patch id but object id set
to zeros since 2nd commit.
I've discovered the issue via the failing tests of
https://github.com/VirtusLab/git-machete, which relies on `git
patch-id`.
Best,
--
Paweł Lipski