The cherry pick will refer to a different history, so it will have a different commit hash (and thus be considered a separate and independent commit by any sane tooling, including Git itself).
This seems to work around that by matching on the commits' summary lines instead, which only (sort of) works because their workflow disambiguates this (1 commit per issue, each commit is prefixed with the issue ID).
Then again, most of their desire for this tool seems to come from their broken rebase-oriented workflow stomping all over commit hashes in the first place (on top of ensuring that what was tested and reviewed no longer matches what was merged, while destroying the history that could help someone trying to diagnose the issue).
Play stupid games, win stupid prizes, I guess. Your history isn't, has never been, and will never be linear. Whether or not you rewrite your logs to make it seem that way.
I think making the commit summary the "id" of this workflow is actually interesting. It is a step towards doing project management in git itself rather then an external tool.
This seems to work around that by matching on the commits' summary lines instead, which only (sort of) works because their workflow disambiguates this (1 commit per issue, each commit is prefixed with the issue ID).
Then again, most of their desire for this tool seems to come from their broken rebase-oriented workflow stomping all over commit hashes in the first place (on top of ensuring that what was tested and reviewed no longer matches what was merged, while destroying the history that could help someone trying to diagnose the issue).
Play stupid games, win stupid prizes, I guess. Your history isn't, has never been, and will never be linear. Whether or not you rewrite your logs to make it seem that way.