Why does a rebase after a cherry-pick not apply the same commit twice?

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.