The git rebase manpage reads:
If
<upstream>is not specified, the upstream configured inbranch.<name>.remoteandbranch.<name>.mergeoptions will be used;[....]
The commits that were previously saved into the temporary area are then reapplied to the current branch, one by one, in order. Note that any commits in
HEADwhich introduce the same textual changes as a commit inHEAD..<upstream>are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped).
And indeed, when I call git rebase master and there is a commit in master with the same textual changes as in my local branch's history, it is ignored. However, I've found that when I call git rebase without specifying <upstream> (which defaults to master), the output of git rebase seems show the same commit not being ignored.
Example
Here's an example to demonstrate this. Here is the git history:
A---B master
\
B' topic
B and B' introduce the same textual changes but have different commit messages. topic is set up to track master.
First, I rebase topic while suppling <upstream>:
$ git checkout topic
$ git rebase master
First, rewinding head to replay your work on top of it...
Nothing happens, as expected, since B and B' are diff-identical.
However, if I omit <upstream>:
$ git checkout topic
$ git rebase
First, rewinding head to replay your work on top of it...
Applying: Branch: topic
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
It seems like git does not skip B' in the second output. Can someone please explain this discrepancy?
(I'm using git version 1.9.4)
This is no longer the case (tested with latest Git 2.38.0). Here is a simple, fully-reproducible test case:
Output of the
rebasecommand:Log output: