Skip to content

Commit

Permalink
git-rebase: document suppression of duplicate commits
Browse files Browse the repository at this point in the history
git-rebase uses format-patch's --ignore-if-in-upstream
option, but we never document the user-visible behavior. The
example is placed near the top of the example list rather
than at the bottom because it is:
  a. a simple example
  b. a reasonably common scenario for many projects (mail
     some patches which get accepted upstream, then rebase)

[sp: Corrected direction of 'HEAD..<upstream>' set comparsion]

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  • Loading branch information
Jeff King authored and Shawn O. Pearce committed Oct 16, 2007
1 parent 5040bef commit ff90546
Showing 1 changed file with 24 additions and 1 deletion.
25 changes: 24 additions & 1 deletion Documentation/git-rebase.txt
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,10 @@ The current branch is reset to <upstream>, or <newbase> if the
`git reset --hard <upstream>` (or <newbase>).

The commits that were previously saved into the temporary area are
then reapplied to the current branch, one by one, in order.
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).

It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
Expand Down Expand Up @@ -62,6 +65,26 @@ would be:
The latter form is just a short-hand of `git checkout topic`
followed by `git rebase master`.

If the upstream branch already contains a change you have made (e.g.,
because you mailed a patch which was applied upstream), then that commit
will be skipped. For example, running `git-rebase master` on the
following history (in which A' and A introduce the same set of changes,
but have different committer information):

------------
A---B---C topic
/
D---E---A'---F master
------------

will result in:

------------
B'---C' topic
/
D---E---A'---F master
------------

Here is how you would transplant a topic branch based on one
branch to another, to pretend that you forked the topic branch
from the latter branch, using `rebase --onto`.
Expand Down

0 comments on commit ff90546

Please sign in to comment.