For each of one or more existing commits, the git cherry-pick <oid> command creates a new commit
with an identical diff to <oid> whose parent is the current commit[2].
Git is following these steps:
Compute the diff between the commit <oid> and its parent.
Apply that diff to the current HEAD.
Create a new commit whose root tree matches the new working directory and whose parent is the commit at HEAD.
Move the ref at HEAD to that new commit.
It is important to recognize that cherry-pick didn't “move” the commit to be on top of our current HEAD.
Instead cherry-pick created a new commit whose diff matches the existing commit.
This way there are two copies of the same diff i.e. code contributed by the same author on the same date.
How is Cherry-picking handled in KEDEHub?
Cherry-picking keeps the author and created date of the original commit in the newly created commit.
The cherry-picked commits have the additional info of who committed at the moment of cherry-picking.
If we ever needed to answer the question "who committed this code the first time?",
we would be able to retrieve that by tracking the source of the cherry-pick and reading this unchanged data.
Here is an example how to asure ourselves that author name and date are preserved in the cherry-picked commit:
We can see that c2 is duplicated in two commits.
However, for both duplicates AuthorDate is the same.
KEDEHub utilizes the unchanged author name and author date to find the cherry-picked copies of the original commit.
Those copies are not included in KEDE calculations.
How to lie with Cherry-picking?
There might be people who would like to game KEDEHub in order to get higher KE$DE.
There are several ways to create false, fraudulent commits using cherry-pick.
If you supply --reset-author as a command line flag, git commit will reset the author to what is configured,
or to whomever you name.
This also renews the author timestamp[3].
You can also specify an author-date at this point in the same way.
The git cherry-pick command won't pass --reset-author when runs git commit,
but here is what things you can do:
If you run git cherry-pick -n instead of git cherry-pick,
then the cherry-pick command won't run git commit.
You'll have to run it yourself.
You can run it with --reset-author, and hence adjust the author and date.
Here is an example how to chance author date with cherry-picking:
We see that commit c1 is created a new but with a different author date.
In this way code changes will be duplicated and if used in KEDE calculations increase individual performance.