The git documentation says the following:

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 HEAD which introduce the same textual changes as a commit in HEAD..upstream are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped).

Which seemed a bit confounding to me. Does this simply mean that any commit in the branch being rebased that doesn't change anything in the branch being rebased onto is omitted from the set of commits to be copied ?

if so:

• what if new_base is specified ? does this change the set of commits from HEAD..upstream to HEAD..new_base ?
• Why use a range ? why not just say "any commits in HEAD which introduce the same textual changes as a commit in upstream are omitted" ?

CodePudding user response：

Which seemed a bit confounding to me. Does this simply mean that any commit in the branch being rebased that doesn't change anything in the branch being rebased onto is omitted from the set of commits to be copied ?

Yes, mainly because in a normal situation, Git would never record an empty commit unless explicitly told so. What you would get instead here is a message "your working directory is clean" returned by git status.

what if new_base is specified ? does this change the set of commits from HEAD..upstream to HEAD..new_base ?

I believe this is what they meant by "upstream" indeed.

Why use a range ? why not just say "any commits in HEAD which introduce the same textual changes as a commit in upstream are omitted" ?

Because that's the way Git actually distinguishes two branches. The bottom commit of this range is the place both your branches have started to fork.

CodePudding user response：

Does this simply mean that any commit in the branch being rebased that doesn't change anything in the branch being rebased onto is omitted from the set of commits to be copied ?

No. To get down to brass tacks, you can see what commits a plain git rebase regards as candidates with

git rev-list --reverse --no-merges @{upstream}..

and the commits it's checking against, to avoid reapplying already-applied commits, with

git rev-list --reverse --no-merges ..@{upstream}

The checking uses git patch-id. To see what git's looking at,

git rev-list --reverse --first-parent --no-merges @{upstream}.. \
| git diff-tree --patch --stdin \
| git patch-id

and

git rev-list --reverse --no-merges ..@{upstream} \
| git diff-tree --patch --stdin
| git patch-id

except that sequence is in the internals of the --right-only the git format-patch --right-only @{u}... the rebase really runs does to get its information.