On Tue, Sep 09, 2025 at 10:58:53AM -0700, Linus Torvalds wrote:
> On Tue, 9 Sept 2025 at 10:50, Linus Torvalds
> <[email protected]> wrote:
> >
> > patchid=$(git diff-tree -p fef7ded169ed7e133612f90a032dc2af1ce19bef
> > | git patch-id | cut -d' ' -f1)
>
> Oh, and looking more at that, use Dan's version instead. You almost
> certainly want to use '--stable' like Dan did, although maybe
> Konstantin can speak up on what option lore actually uses for
> indexing.
It uses --stable.
> And you *can* screw up patchid matching. In particular, you can
> generate patches different ways, and patch-id won't generate the same
> thing for a rename patch and a add/delete patch, for example (again:
> the traditional use case is that you generate the patch IDs all from
> the same tree, so you control how you generate the patches)
We can't control how the patches are generated by submitters. If someone
generates and sends them with --histogram, this won't work. Here's an example
right from your tree:
$ git show 1c67f9c54cdc70627e3f6472b89cd3d895df974c | git patch-id --stable
| cut -d' ' -f1
57cb8d951fd1006d885f6bc7083283d3bc6040c1
$ git show --histogram 1c67f9c54cdc70627e3f6472b89cd3d895df974c | git
patch-id --stable | cut -d' ' -f1
47b4bfff33d1456d0a2bb30f8bd74e1cfe9eb31e
Or if someone generates with -U5 instead of the default (-U3):
$ git show 1c67f9c54cdc70627e3f6472b89cd3d895df974c -U5 | git patch-id
--stable | cut -d' ' -f1
0b68dd472dc791447c3091f7a671e7f1e5d7a3d2
This is more than just annoying -- this can be misleading and confusing. If
the submitter sent v1, v2, v3 with the default parameters and then sent v4
with --histogram, then you may think v3 was the final version that got applied
and it will waste a lot of your time trying to figure out why it doesn't match
what's in the tree.
I don't have precise statistics, but I do have firsthand experience trying to
make this work with git-patch-id, because this is how git-patchwork-bot works,
and we can't match a significant portion of commits to patches.
-K
