Detect a commit diff/patch/hunk in another branch similar to the way cherry-pick does

Question

Using git, I would like to check which, if any, of the diffs from a specific commit have been applied (and where) to a specific branch.

cherry-pick does this (except for the "where" part) when you cherry pick a commit and only applies the diffs that haven't been applied to that branch already. For example, if I commit two file changes to a topic branch, I manually apply one of those same file changes to master, when I cherry-pick the commit with the two file diffs from topic to master, it only applies the un-applied diff. To demonstrate this, run the following commands from an empty folder and look at the final diff output:

git init
echo file 1 > file1.txt
git add .
git commit -m "Initial commit"
git branch topic
echo file 1.1 > file1.txt
git add .
git commit -m "Change file1.txt on master"
git checkout topic
echo file 1.1 > file1.txt
echo file 2 > file2.txt
git add .
git commit -m "Change file1.txt and add file2.txt on topic"
git tag to-cherrypick
git checkout master
git cherry-pick --no-commit to-cherrypick
git diff --cached

The diff output is:

diff --git a/file2.txt b/file2.txt
new file mode 100644
index 0000000..6bb4b1d
--- /dev/null
+++ b/file2.txt
@@ -0,0 +1 @@
+file 2

Showing that even though the cherry-picked commit had two file changes, it detected the first one was already applied.

So my question is: Does git have an exposed plumbing (or somewhere between plumbing and porcelain) command that will look at the hunks in a commit and check for each hunk in another branch, showing the commit where each hunk is applied?

And if that command doesn't exist, what are some pathways to finding that? I'm already looking into possibly writing a script/program to break the commit into it's hunks, run patch-id or something similar on each, then looping through the other branching starting at the common ancestor and doing the same for each commit, and comparing hunks. I would like to avoid writing that if it is already exposed -- I know it exists because cherry-pick does that (except for showing the "where").

UPDATE: git cherry will do some of what I am looking for. It will tell me which commits in one branch have one or more diff hunks that haven't been applied to another. It does not tell where those diff hunks were applied or if a commit has hunks that were applied and others that weren't.

Answer 1

As commented:

The best you can get with relatively easy scripting is to separate out each diff hunk (the perl code that implements add -p and reset -p does this), run it through git patch-id (multiple internal places in Git do this, including git rerere), and save the patch IDs somewhere so that you can compare them.

First: there is no more "perl" version of any Git command.
Everything has been rewritten in C.

For instance git add -p was rewritten inc C as part of Git 2.25 (Q4 2019) (commit f6aa7ec)

Second, if you are using git patch-id, make sure to use Git 2.36 (Q2 2022).

Unlike "git apply"^(man), "git patch-id"^(man) did not handle patches with hunks that has only 1 line in either preimage or postimage, which has been corrected with Git 2.36 (Q2 2022).

See commit 757e75c, commit 56fa5ac (01 Feb 2022) by Jerry Zhang (jerry-skydio).
^{(Merged by Junio C Hamano -- gitster -- in commit d077db1, 17 Feb 2022)}

patch-id: fix scan_hunk_header on diffs with 1 line of before/after

^{Signed-off-by: Jerry Zhang}

Normally diffs will contain a hunk header of the format "@@ -2,2 +2,15 @@ code".
However when there is only 1 line of change, the unified diff format allows for the second comma separated value to be omitted in either before or after line counts.

This can produce hunk headers that look like "@@ -2 +2,18 @@ code" or "@@ -2,2 +2 @@ code".
As a result, scan_hunk_header mistakenly returns the line number as line count, which then results in unpredictable parsing errors with the rest of the patch, including giving multiple lines of output for a single commit.

Fix by explicitly setting line count to 1 when there is no comma, and add a test.

apply.c contains this same logic except it is correct.
A worthwhile future project might be to unify these two diff parsers so they both benefit from fixes.