Hi, Let's consider the following patch (======= are delimiters): ======= commit 8db0161b9bb897d9cbe68bc1ed8ba8f43f39da00 Author: Tester Test <tester@xxxxxxxx> 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 <tester@xxxxxxxx> 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