Rebasing Branches - Git Recipes - page 240

The parameter master..feature specifies a set of commits. You can treat it as
a subtraction operator:
feature - master
or more precisely:
revisions included in feature - revisions included in
master
That's how you can discover which set of commits were or will be moved during re-
base to some other location. The command:
$ git log --oneline master..feature
issued before rebasing will print the commits that will be moved. When issued after re-
basing it will print the commits that were moved.
Now we want to produce the patches for these three commits. A patch is a text file
that describes precisely the changeset to be introduced in your project files. When is-
sued in the feature branch, the command:
$ git format-patch --ignore-if-in-upstream master
produces three text files named 0001-f1.patch , 0002-f2.patch , and
0003-f3.patch . The first file is a patch for the revision f1 . The second file is a
patch for the revision f2 . And the third file is a patch for the revision f3 . The paramet-
er -- ignore-if-in-upstream guarantees that only the patches for commits that
were not already merged in the master branch are generated. This option becomes
necessary when you want to generate patches numerous times for a lot of branches.
All generated files are new and untracked, as proved by the $ git status -s
command:
?? 0001-f1.patch
?? 0002-f2.patch
?? 0003-f3.patch
In Recipe 5-6 you learned that new untracked files do not influence the checkout
command. You know that a current branch can be switched—untracked files will re-
main unchanged. That's exactly what we want to do because we want to apply the