Question

When you cherry pick a commit from one branch (say “topic”) to another (lets call it “master”) the history of that commit is rewritten, its hash changes and it effectively becomes a new, independent, commit.

However when you subsequently rebase topic against master git is clever enough to know not to apply to the commit twice.

Example:

A --- B <- master
      \
       \---- C ---- D <- topic

$ git checkout master
$ git cherrypick D

A --- B --- D' <- master
      \
       \---- C ---- D <- topic

$ git checkout topic
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying 'C'

A --- B --- D' <- master
            \
             \---- C' <- topic

How does this magic work? Ie. how does git know it should apply C to D’, but not D to D’?

Answer 1

The answer is in the man page for git-rebase:

Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD.. are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped).

Rebase looks at the textual change, and refuses to replay that commit if it already exists on the branch you’re rebasing onto.