Taking just the diff

But that’s exactly what I am talking about. When you merge a branch and resolve conflicts, you can make any changes you want as part of the merge. You could even end up not applying any of the change ostensibly being merged in (perhaps because the affected feature and its source code no longer exist in your branch). But still git will show that you performed a merge and the other branch is now an ancestor of yours. And this is by design.

(Another way to see whether a branch has been merged would be to look at the code and check the changes in the other branch are present in yours. This is what people sometimes had to resort to in older version control systems without change tracking, or which were not distributed, or indeed if they had no VCS at all. Both approaches have their advantages, but often we prefer the cleaner one based on explicitly tracking commit history.)

Now moving from whole branches to individual changes. You could try to work out whether a cherry-pick has been applied by looking at the current state of the code, or going back over the branch history to see if a similar-looking diff has been applied in the past. But as you say that falls down if there were conflicts or for other reasons the patch wasn’t applied exactly.

Instead, I suggest a metadata-based approach where you can create a “disembodied commit” which has a patch to apply but no ancestor commits. Merging this commit into your branch is usually simpler than merging a whole other branch, which may have unrelated changes (unless your programmers are very disciplined about always creating “daggy fixes” where the commit fixing a bug is an immediate child of the one that introduced it). Indeed merging this disembodied commit is the same as cherry-picking it, as far as the code goes. But unlike cherry-picking, the disembodied commit keeps the same SHA, and is now an ancestor of your branch. That would make it easy to ask “has this fix been applied?” without having to match the file contents, and even when the fix is only given as a text diff against some slightly different version of the codebase.

The SHA of the disembodied commit could be the hash of the original set of changes (or textual diff) but that same SHA would still be used even if you had to resolve conflicts on merging. Again, just as happens for regular branches and regular merges.